This implies that Rust build times haven't been a topic of discussion for the last 10 years. They don't have long build times just for funsies, Rust is completely different from Lisp.
The answer: dependencies (My compiler has virtually none, intentionally)
Rust has a very small stdlib, so you are forced to bring in dependency crates, and not just a few. Many programs have 50-100 or more, and they all have dependencies, and so on. Contrast with Go where it has a culture of few dependencies, and those project have few dependencies. Your Rust compiler is doing a lot more work for what appears to be the same program as in other langs, but ultimately is a lot more code (typically).
To make matters worse, cargo does a decent job of parallelizing the builds, but it can only do so a) at the crate level b) only as much as the dependency graph allows.
I don't write much Go but it seems like it has a good balance when I do.
It may be a bad example, but even in rust generating a random number involves pulling in 6ish crates
└── rand v0.10.3
├── chacha20 v0.10.2
│ ├── cfg-if v1.0.5
│ └── rand_core v0.10.1
├── getrandom v0.4.3
│ ├── cfg-if v1.0.5
│ ├── libc v0.2.191
│ └── rand_core v0.10.1
└── rand_core v0.10.1That said, I missed the borrow checker.
For all of Python's warts, it at least makes everyday structures and operations you might want to use fairly painless, and it keeps expression fairly standardized. Leave external libraries to build things that are actually interesting, rather than scaffolding and infrastructure that the language vendor is better off providing.
I disagree, skinny stdlib is an option that you intentionally leave open. You let the ecosystem around you explore good solutions first before you commit early or exhaust the air in the room for better ideas.
Fucking lol. I have an almost decade-old laptop and compile projects way faster. Ocaml and Go both compile 100K LOC projects under 1sec.
And to make a point, the Turbo Pascal 5.5 compilation times, from 1989 marketing brochure
> Fast! Compiles 34 000 lines of code per minute
This was measured on a IBM PS/2 Model 60, a computer model from 1987, with a 80286 running at 10 MHz, limited by 640 KB, with luck one would expand it up to 1 MB and use HMA, in what concerns using it with MS-DOS.
You can get the brochure at https://archive.org/details/bitsavers_borlandtur5.5Brochure1...
So one would expect that at very least for debug builds in 2026, one would always have blazing fast build times.
Which is why languages like OCaml, Go, Zig, D, Delphi and co, are not doing something spectacular, rather pretty much what should be the norm, and unfortunately got sidetracked somehow.
Assuming for a second this is true.
Why?
We solved separate compilation a few decades ago. So if those dependencies are causing your compile times to spiral out of control, then something is wrong.
For example unlearning separate compilation, as we seem to have done.
The majority of time is spent between the trait solver and LLVM optimization passes. There is work being done to improve the trait solver and to produce more efficient LLIR code from the get-go (so LLVM has less to optimize).
People should stop abusing the language. Some of my Rust projects compile faster than the time it takes JVM applications to start. Obviously, once the tests are compiled, the test suite with hundreds of tests finishes in less than one second, meanwhile the JVM tests might take 30 seconds.
It is a matter of priorities.
If we stopped treating the compiler as a one-shot program, we could theoretically shorten this edit-build-test loop by 99%.
Its basically a better language for software you write in C at the cost of horrible compile times.