← Back to context

Comment by feelamee

2 days ago

maybe rustc will never be re-architectured (although it has already been rewritten once), but with developing rust standard there will come new Rust implementations. And there is a chance that they will prioritize performance when architecting.

The root cause of the problem is not the compiler. It's the language. If you compile a C program that links to a lot of libraries, the compiler compiles just the source code you wrote, and then the linker combines that with the pre-compiled libraries. Linking is a comparatively fast operation, so the total time is roughly what it took to compile just your source. Rust has chosen a design that requires it to compile not just your source, but also a fair chunk of the the libraries source code as well. Those libraries are usually many times the size of your source code.

Unsaid here is modern C++ programs suffer from the same problem, because modern C++ libraries are mostly .h files that are stuffed full of templates. The outcome is the same as Rust: slow compilation, even with a GNU C++ compiler.

The outcome is the same because Rust's generics have a lot in common with C++ templates. Both a generic Rust function and a C++ template are a kind of type safe macro. Like all macro's they generate source code, customised by the parameters the caller supplied, and because its customised that source code can't be pre-compiled and put into a library.

The downside of this is not just slow compile times. It's also means very fat binaries. And it means security issues in a library can't be fixed by shipping a new version of a dll, you have to recompile the original program.