Just found this article. This is about writing very large games in C++, but I think it could be of interest of Rust people too:
He shots down large features of C++:
Templates suck as they cause link-time spam and compile times to skyrocket. They severely bloat the size of the debug symbol file, which on large projects can easily reach several hundred megabytes of data. Abstractions built with templates perform differently depending on whether compiler optimizations are enabled or not (every tried debugging Boost code?). They’re essentially unusable on large code bases beyond container-of-T and simple functions.
RTTI sucks because it doesn’t do what anyone wants, and you can’t even rely on it returning a type name formatted in a certain way.
Classes suck because their guts have to be in headers for all to see.
I have/is been working with large C++ code bases (I also worked with the author of the article) but I would like to add some things here.
Compilation time is a big pain for large C++ projects for sure. Templates makes it way worse as templates blow up headers and then extra time is spent in the linker to remove the "duplication"
Rust model is different which more of a module approach but right now the compilation time for Rust is much slower than C++ so for Rust (right now) it would likely be worse at that scale. Now C/C++ compilers has had many years to improve over compared to Rust of course so I'm sure this will improve then Rust also does a lot more checking during compilation than C++ does.
I think D language is a little better than C++ on this. The duplication is still present, but I think it's less of a problem (and in Ada I think it's even less of a problem). Compared to C++, D templates are also simpler (but overall the compile-time features of D are better).
I have read something about this. I think the Rust borrowck is not using lot of compilation time. And the other checks done by the Rust compiler are not that different from the ones done by the D compiler, that is faster. I think the type inferencer of Rust, that works inside functions, takes a good amount of compilation time. And some other time is used by LLVM to reduce the significant amount of intermediate code given to it by the Rustc front-end. This last problem is currently worked on...
One thing I am very much looking forward to that I believe will greatly speed compilation is compiling only changed files. As I understand it, currently Rust is compiling every single file, even if you only changed a 0 to a 1 somewhere in some file.
Yeah I'm not really that worried about the compile times as is for Rust. I think/hope there is lots to improve in this area. LLVM by itself should be quite fast as Clang (which uses LLVM) is quite fast but it comes down to how LLVM is being used I suppose.
I have read somewhere that a lot of the compilation time is spent on optimization in LLVM, and some of this can be cut by making rustc generate more optimal code from the beginning. I can't say to what extent that is true, but it sounds like there's a lot of room for improvements there. That, together with the planned support for some kind of incremental compilation, sounds great.
I think D language is a little better than C++ on this. The duplication
is still present, but I think it's less of a problem (and in Ada I think
it's even less of a problem). Compared to C++, D templates are also
simpler (but overall the compile-time features of D are better).
I think the main problem is that developers who face these hourly compilation times with C++, never had the opportunity to use other compiler toolchains from languages that have generics and proper modules.
Besides the ones you mention, Eiffel and Modula-3 are another examples..
So they equate the encapsulations provided by C++ with slowness, regardless of the language.
Hopefully Rustc gets to improve its compile times, specially now that C++ is finally getting modules.
