From my experience building (not writing) relatively complex Rust applications like Alacritty, it's really not that bad. Building for release is definitely slower than C++, but development builds are almost always instant for me, as they're done incrementally.

Rust is much better at caching the intermediate results of compilation. First time compilation might take some time, recompilation will be faster though.

Most of the time, I let my IDE check the code with rls, rust-analyzer or cargo check which invokes the rust-compiler without doing the costly code generation part with LLVM, so it is usually fast enough checking huge projects while writing or at least when saving.

cargo doesn't do a terribly good job of caching dependencies.

Might be better than whatever C++ does though.

Currently C++ is still a better experience, because using binary dependencies is quite common, so you don't compile the whole world, rather just your own application.

Then most organizations have staging areas where you can share binaries across the company.

And the two package managers that have been growing community support, conan and vcpkg, support caching and distribution of binary dependencies.

No doubt cargo will eventually get something similar, it just isn't there today.

You can do this with a build script.

So goodbye declarative builds.

I thought I cared about declarativeness, turns out I don't.

Experience has taught me to always care about it, except when working on throw away hobby projects with teams of one, turns out not using it doesn't scale across organisations and makes for very unhappy DevOps teams.

Slow is relative. On my machine I can compile all of Chromium in ~15 minutes. I am one hugely impatient person when it comes to compile times, so I watch things closely.

But just like anything else given enough time, money and harddisk space anything is possible :)

I'm not sure what fast or slow is. I think on average I spend 1-10s compiling. Eg when I run my tests, or run a server. However that is during my normal workflow. Ie the thing I do 500x a day.

If I was to nuke my target directory _(the compile cache)_, it would take minutes. Not sure how many honestly, because when I do it, I rarely wait for it.

So the compiles are definitely slow, but for me it's only bad when dependencies are needing to be compiled. Which is rare.

If you don't cache your dependencies well, like in a poorly written CI pipeline, things will suck though. 20 minute builds at work (slow build machines) are common for us due to some poorly done caching.