C++, of course, has the same choice between virtual methods and templates, "interfaces", inline and external method implementation syntax, etc, although the separate vtables are a nice trick and traits look interesting. So I'm curious about one thing (which would be obvious if I'd used Rust, but isn't apparent on Google):
What's the compilation speed like?
C++'s tendency to stick template functions in header files is a curse on compilation speed compared to C. Rust's solution is apparently to compile all modules in a crate together, which at least avoids instantiating the same templates more than once when compiling from scratch, but sounds like it would make incremental compilation times even worse. I am interested in Rust, but slow compilation drives me crazy.
(And what are the rules for importing classes between crates - how do template functions work, are there any guarantees for changes to a class that won't prevent code that was compiled with an old version from working?)
Compilation speed is not as fast as we would like yet. A lot of that is simply due to generating too much code, which largely is an artifact of the way we implement unwinding. We're working on redoing that to improve code size and reduce compilation times. The monomorphization pass (which is the analogue to template expansion in C++) is pretty fast, because we operate on largely precompiled, serialized ASTs instead of reparsing and typechecking everything from scratch. (Also, we only bother to deserialize the functions you actually use.)
You can draw the boundaries between compilation units however you'd like. If you want incremental compilation, use many crates; if you want easier dependency management, use fewer crates. By default, crates are loaded dynamically at runtime, but you can statically link crates together and inline across crates for production.
The Rust compiler tracks breaking API changes and updates your crate UUID automatically. You can change private APIs and dynamically linked code as you'd like without causing dependent crates to be recompiled, but changing an inlined template function will cause your crate UUID to change, which triggers recompilation of dependent crates. The UUID is essentially just a large hash value derived from the signatures of all the public items in your crate.
At the moment, this is unimplemented, but it's intended that you be able to change the bodies of non-inlined generic functions without causing recompilation of your callers. This works because a non-inlined generic function can only be called with pointer types, which means we can generate one piece of code for the generic function and use that. Inlined generics can be called with any value and the code is duplicated for each value you called it with, so changing the body of one of those does trigger recompilation of dependent crates.
What's the compilation speed like?
C++'s tendency to stick template functions in header files is a curse on compilation speed compared to C. Rust's solution is apparently to compile all modules in a crate together, which at least avoids instantiating the same templates more than once when compiling from scratch, but sounds like it would make incremental compilation times even worse. I am interested in Rust, but slow compilation drives me crazy.
(And what are the rules for importing classes between crates - how do template functions work, are there any guarantees for changes to a class that won't prevent code that was compiled with an old version from working?)