That sounds a bit like using the latest features in the C or C++ standard, and then be surprised that many compilers cannot compile your code.
When a language develops quickly it is a good if people use the latest version to test new features to get experience.
When a language become mainstream, change will be much slower. Rust compilers will be shipped with operating systems, and people will write code that can be compiled by those older compilers.
There is a lot of C code that targets C99. Because that's what you can rely on if it has to run everywhere.
> When a language become mainstream, change will be much slower
I wouldn't assume that. JavaScript is about as mainstream as it gets, and that's also on a 6-weekly release schedule.
> Rust compilers will be shipped with operating systems, and people will write code that can be compiled by those older compilers.
Rust compilers are already shipped with operating systems, but for the most part (a few really foundational crates aside), people are not writing code that can be compiled by those older compilers. They're telling people to install a newer version of Rust. Which is pretty reasonable given how easy it is to manage rustc versions with rustup.
This may change with the creation of certified compilers for things like the automotive industry. But then, they're probably pretty used to maintaining their own library ecosystem anyway.
> There is a lot of C code that targets C99. Because that's what you can rely on if it has to run everywhere.
Yes, but one of the best things about Rust is that you can target the latest compiler version, and it still runs everywhere! That's why people don't like the possibility that this might change with the introduction of gcc-rs. We shouldn't accept crappy C toolchains as the standard.
I think there are a lot of people who don't want a new compiler every few months. Obviously, the people who arrive first at a new language are people like the latest greatest.
Take for example reproducible builds. Obviously, you only get the same binary output if you use the same compiler version. In that context, it doesn't make sense to keep around every version ever released of the Rust compiler.
In particular, if operating systems are going to use Rust in their kernels or base systems, then it is very unlikely that they are just going to use rustup to get the latest compiler. They will carefully vet each compiler release to make sure that everything that worked in the past, still works.
Rust being a compiler means that for every processor architecture somebody has to create the back-end. This means that if the current LLVM-based rust compiler will remain the only usable Rust compiler, there will be a lot of places where Rust cannot be used (unless LLVM will be the only compiler back-end in the future).
For now, at least, Rust for Linux actually requires Nightly features, so it's even less stable than the requirements of many relatively fast moving but popular Rust crates in userspace.
As with Firefox, Linux (ab)uses the compiler's own environment hack to say "No, I want nightly features, I don't care that this invalidates my warranty" despite using a stable compiler.
The actual version used is, I think, currently 1.66 (so, about three months old).
There is nothing crappy about stability. One of the most annoying things about more modern languages is this assumption that in so much of the ecosystem that I will go install the latest version of cool-lang compiler. I really like being able to build software with the tool chain that comes with my distro. Maintaining endless versions of all these things is a hassle.
When a language develops quickly it is a good if people use the latest version to test new features to get experience.
When a language become mainstream, change will be much slower. Rust compilers will be shipped with operating systems, and people will write code that can be compiled by those older compilers.
There is a lot of C code that targets C99. Because that's what you can rely on if it has to run everywhere.