When people complain about rust compile times are they complaining about cold/clean compiles or warm/cached compiles? I can never really tell because people just gripe "compile times".

I can see how someone would come to rust, type `cargo run`, wait 3-5 minutes while cargo downloads all the dependencies and compiles them along with the main package, and then say, "well that took awhile it kinda sucks". But if they change a few lines in the actual project and compile again it would be near instant.

The fair comparison would be something akin to deleting your node or go modules and running a cold build. I am slightly suspicious, not in a deliberate foul play way but more in a messy semantics and ad-hoc anecdotes way, that many of these compile time discrepancies probably boil down more to differences in how the cargo tooling handles dependencies and what it decides to include in the compile phase, where it decides to store caches and what that means for `clean`, etc. compared to similar package management tooling from other languages, than it does to "rustc is slow". But I could be wrong.

cargo run is a command you'd generally use to actually get something running I guess. This is not going to be incremental development in many cases which focus on unit tests I guess.

FWIW cold builds (i.e., in docker with no cache) of cargo are much slower than go, hanging for a long time on refreshing cargo.io indexes. I don't know exactly what that is doing but I have a feeling it is implemented in a monolithic way rather than on-demand. Rust has had plenty of time to make this better but it is still very slow for cold cargo builds, often spending minutes refreshing the crates index. But Go misses easy optimizations like creating strings from a byte slice.

So it is what it is - Go makes explicit promises of fast compile times. Thanks to that, build scripts in go are pretty fast. Any language that doesn't make that explicit might be slow to compile and might run fast - that's totally fine and I would rather have two languages optimized to each case than one mediocre language.

You don't even need a separate language, there's already a "fast" compiler for Rust based on cranelift which is used in debug builds by default.

> We were able to benchmark bjorn3's cranelift codegen backend on full crates as well as on the build dependencies specifically (since they're also built for cargo check builds, and are always built without optimizations): there were no issues, and it performed impressively. It's well on its way to becoming a viable alternative to the LLVM backend for debug builds.

And the Cranelift codegen backend itself is also clear about it not being ready yet: https://github.com/bjorn3/rustc_codegen_cranelift

(To be clear, I am super excited about using Cranelift for debug builds. I just want to clarify that it isn't actually used by default yet.)