[rust-dev] C++ to Rust - Is that about right?

Andrew Poelstra apoelstra at wpsoftware.net
Tue Jul 15 07:18:00 PDT 2014


> On Tue, Jul 15, 2014 at 5:25 AM, Christoph Husse
> <thesaint1987 at googlemail.com> wrote:
> > Further I notices that they often seem to mix test and production code
> > which is also strange to me. For instance with test driven development
> > you have tons of problems with that approach. Only mentioning a few:
> >
> > 1) Test code will most likely be at least in the order of magnitude of
> > the production code it tests, so putting them together in the same
> > directory or even file will get unhandy pretty quickly

You've mentioned file size a few times. In vi you type `:vsplit` to
split your screen into two views of the same file, then you type
`/functionname` in one to go find the relevant function. Alternately,
if your functions are in separate files, you add the relevant file
name to the `:vsplit` command. So the amount of effort spent editing
is basically the same. I expect most IDE's that are not structured
around the C#/Java way of doing things are similarly filesize-agnostic.

On the other hand, /conceptually/ I find Rust's module system to be
much easier to reason about. Even in OO-only languages class boundaries
are typically not functionality boundaries (unless you have monolithic
classes in which only a small subset of functionality is ever used at
any time --- but then you have no modularity, an even worse curse). In
Rust, where precisely-scoped traits provide the majority of functionality,
more than the `struct Struct`/`impl Struct` pairs that are used to
emulate classes, this is even more true.

> > 2) The test code this way can access internals of the module, which by
> > definition should be avoided, since internals are implementation
> > details and if your tests use them you will get cascades of test
> > failures for each simple design change

Well, in your public interface tests, don't use private functions. When
replacing/restructuring private functions, delete the tests which target
those. In other languages I find it very inconvienient to have to switch
contexts to work on tests, and to have no ability to unit test functions
which are not publically exported.

> > 3) Performance, mostly. To have fast iteration cycles, tests most
> > likely need to be grouped an executed/compiled intelligently (which
> > needs some compiler or IDE support) so that only tests that are
> > relevant to the changes you just made will be compiled and executed.
> > If you mix tests with production code then then it is a lot more
> > involved to sieve out tests during compilation, linking and
> > execution... that not need to run.
> >

Well, Rust in general needs some work done on partial compilation :).
I'm sure optimizing test compilation will come as part of that.

-- 
Andrew Poelstra
Mathematics Department, University of Texas at Austin
Email: apoelstra at wpsoftware.net
Web:   http://www.wpsoftware.net/andrew

"If they had taught a class on how to be the kind of citizen Dick Cheney
 worries about, I would have finished high school."   --Edward Snowden

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140715/2755a50b/attachment.sig>


More information about the Rust-dev mailing list