> and the approach of compiling everything from scratch.

That is not really true. Yes, it would help first compiles a bit, but only the initial compiles. That's a one-time improvement, that while important, doesn't solve the big problems.

You keep downplaying this, however this is a problem I never have with other compiled languages, which don't force developers to buy a new computer just to make it barebable.

With Rust is almost impossible, just to check a random project without investing the required time to wait for its build to finish.

Also maybe I am special, but it is quite typical to switch project branches quite often, or just get libraries from another project.

All of which I can easily do via binary libraries stagging.

Again, the issue of compile times is more complex than "just do this one thing and it's fixed."

After you first cargo build, you have all of the dependencies pre-compiled. Every single "cargo build" after that's compile time would be completely unaffected by pre-built dependencies. You could try sccache; builds are still slow. Most people care about those secondary builds, not about the initial build, so telling them that this solves their problem is simply not true. It's not downplaying it, as I said, the first builds are also important. Unfortunately, it's just not that simple.

If solving Rust builds were as easy as this, we'd have just done it long ago. We care tremendously about improving compile times. It is a constant request on surveys. We put a lot of engineering work into this.

I just use Rust for toy projects, my work is all around Java, .NET and C++, so my feedback is more from the language geek point of view that would like to see Rust gain more adoption on the kind of workflows I use those languages.

So while it may seem like bashing, it is more trying to be a positive critic of something that real matters and is a show stopper for some environments.

In any case I look forward to any improvement in build times, and an eventual story regarding binary libraries.

I don't think it's bashing, I just don't think that it's going to be anything more than one small part of an overall improvement strategy, and isn't the most important one.

Good to know that you don't take it the bad way. All the best for Rust efforts.

If you work on multiple branches you could use git worktrees

(Also, the only time multiple branches cause issues is if the two branches have different dependencies, and again, only on the first compile. Both the source and the compiled artifacts don't live in source control, and so swapping branches doesn't trigger a re-build of them.)

There is work on integrating Cranelift into rustc (https://github.com/bjorn3/rustc_codegen_cranelift) so that rustc can compile to bytecode for the Cranelift JIT.

I am aware of it, on my toy projects it saved 5 minutes out of 20 in a clean build.