This compiler is on the other hand naturally not available on all platforms and is not appropriate for all contexts. Alternate implementations could have filled these gaps, but they're not there.
The fact that the compiler defines the language and vice-versa enables additional flexibility in changing the language/compiler and development speed at the cost of instability. Different projects may tolerate different amounts of instability and for those that are more conservative Rust may not be an appropriate investment.
With C++ one can code for a specific compiler or in a standard way. One can pick C++98 or 17 or anything in between. All of these are supported options and they give C++ its massive breadth and offer the most flexibility to teams. There's obviously disadvantages associated with all that, but claiming that diversity is a weakness is not generally true.
There are already alternative compilers, though most of them are WIP, e.g. mrustc[1], rust front-end for gcc[2][3], or using cranelift[4] for the back-end.
[1] https://github.com/thepowersgang/mrustc
[2] https://github.com/sapir/gcc-rust/tree/rust
It would be interesting for example to see if e.g. the 2015 edition will still be usable/used 9 years later (like C++11) or even ~20 years later (like C++98) but we have some way to go before we can find that out.
On the other hand, there's something exciting about being on the bleeding edge. Right now I'm using C++17 and would probably jump on C++20 when it becomes widely available. But having the knowledge that I have the rock-solid C++11 at my disposal and knowing that it will likely be there for decades gives me a feeling of security that's hard to beat.
Lib A compiled with edition 2018, talking callbacks to functions implemented in Lib B with edition 2020, Lib C edition 2030 importing Lib D edition 2025.
Naturally, I am also assuming that for pleasing the commercial users of binary libraries, typical in C and C++ universe, all those crates are only available as binary libraries being pulled into a multi-edition final executable.
How exactly is having one compiler defining what is okay and what is not worse than "what we have now"? The multiple implementations of C++ are all incompatible with each other in various subtle ways, produce code which works differently and at the end of the day everyone just takes one and says "we write C++ which works with <compiler>" and that's it.
> When Mozilla announced they were getting rid of Rust teams, all we heard from said Rust devs was that this doesn't spell the end for Rust. My impression was that they were mainly motivated by advancing their language rather than, you know, implementing a browser.
Why exactly is it a problem that the core team of a language is interested in the language? Or do you want to imply that the rust devs working on Firefox weren't interested in it? All the progress Firefox made in the last few years tells a very different story (yes, not all of it is due to rust, but a relevant part is).
> And to this date, I haven't really read a critical post-mortem addressing claims that Rust can actually replace C or C++ in the areas where these languages are essential. Apart from kernels and drivers (where Rust seems an outright no-go), C is traditionally used for higher-level language runtimes and compilers/interpreters/VMs. But Rust's borrow checker is a bad fit for just about any text book algorithm and technique in that space. Hell, even Rust devs themselves say implementing a DOM is about the worst use case for Rust.
If you haven't read any critical postmortem about Rusts difficulties in these spaces you haven't looked around very much. This is an impression I generally get from your post. You don't like Rust (for some reason, it's not very clear what it is) and seem to have an axe to grind with it. Which is .. okay? No one forces you to like a language, but doesn't make for a very interesting conversation.