Faster compiler is nice, but you know what's faster? Not having to compile anything. I'm also looking forward to crates.io serving precompiled crates (https://www.ncameron.org/blog/cargo-in-2019/)
I'm a Rust noob but I think skunkopalypse was making some good points. I wish people didn't vote down his/her comment to death and actually replied to it so I could learn why he/she wasn't right.
I too think that precompiling crates won't really solve the problem.
If you compare the compiled artifact (rlib) of a crate with the source code, you'll quickly see that the compiled artifact is much larger than the source code. libglutin-0c732c31a1d003fb.rlib has 8.1 MB while glutin-0.22.0-alpha1.crate has 53 KB.
Most people have shitty internet. And often it's nothing you can do about it because you have shitty ISPs. You can buy a computer with good CPUs and those are usually cheaper in comparison than good internet for a year, at least in many rural areas in the US. It's not just the US, some other countries have it even worse.
Now of course if you have good internet and a bad CPU it's a good deal, so there should definitely be an option to use it, maybe even with autodetection. But I think cargo has too much dependency on the internet, not too little. There should be no manual input required to turn off precompiled crates downloads if it is faster to compile the crates locally.
Will they have a trusted compile farm, only supporting a subset of targets, or involve some kind of distributed trust model supporting whatever people use? Will it be greedily populated with a specific subset of targets / features or lazily populated based on combinations people actually use?
Crates.io is already a security trainwreck in progress. Do we really need to add even more attack vectors?
It's also solving a non-problem. I modify source code downloaded from crates.io zero times per day, so I compile each crate only once. Compile times matter for code I write myself: I modify (and therefore compile) that code dozens of times per day.