Why doesn’t Rust care more about compiler performance?

59 points by ajdecon


jmillikin

The article touches on this very briefly, but IMO a lot of the blame for Rust’s reputation for slow compilation rests on the shoulders of Cargo and crates.io.

In a typical C/C++ project the build system works by taking each source file (*.c *.cc) and executing a compiler process to convert that source file into object code. This is inherently scalable to very large amounts of CPU cores – a big C++ project will happily run hundreds of gcc processes at once. The only real scalability limit is RAM, because you can shard the compilation but you can’t shard ld.

In Rust the unit of compilation isn’t source files, it’s libraries (“crates”) – you run one rustc per library, it spits out metadata and object code, and if you change one source file then you have to recompile the entire library. This implies that the natural translation from C++ to Rust would have each Rust project consist of dozens or hundreds of small libraries, and indeed if you structure a Rust project that way then the compilation is as fast or faster than C.

However, the Rust project’s official build system (Cargo) and official package registry (crates.io) are in practice incompatible with this approach:

I think if the Bazel/Buck/Pants approach was more visible to Rust maintainers, and they got to experience what it’s like to build a truly large project in ~10s and run the full test suite in ~30s, then they would take a step back and look at Cargo and ask themselves “what the hell are we doing here?”.