I'd go as far as to claim that having multiple independent implementations is a basic requirement for any programming language which has any aspirations of being production-ready.
I'd go as far as to claim that having multiple independent implementations is a basic requirement for any programming language which has any aspirations of being production-ready.
It seems you're oblivious to the fact that projects such as swc[1] exist, and have been adopted by projects such as deno.
[1] https://swc.rs/
> Elixir etc
I'm not familiar with Elixir nor am I in a googling mood. Nevertheless that was an awfully short list. Why is that?
Here is an interview with them: https://www.totaltypescript.com/rewriting-typescript-in-rust
What leads you to believe that the lack of alternatives leads to enabling "a lot of cool tooling"?
> and great new features are introduced quickly in the official implementation.
That has zero to do with existing only a single implementation, and everything to do with having developers working on unstable releases and a poor job thinking things though by writing stuff down both as proposals and specifications.
If there is a specification that was discussed and thought-through by competent individuals, nothing stops anyone in the world from reading the specs and implementing the same features.
Rust projects have settled on Cargo, which gives them uniform way of building, testing, getting dependencies, docs generation (https://docs.rs), IDE support, etc. (https://lib.rs/development-tools/cargo-plugins)
Contrast this with C which has several compilers and plenty of build systems to choose from, often more flexible and advanced than Cargo, but the fragmentation means that C projects are snowflakes, and tooling needs to be configured for each project and compiler combo. For every build system X there's someone who says it sucks and you should be using Y instead.
However, I don't think GCC will cause similar fragmentation problems for Rust, because there are already 100K rustc+Cargo packages in existence, so it has no choice but to follow and be compatible with them.
I used to work on the Haskell compiler GHC. Haskell has had many alternative implementations over the years. But they were often nowhere near the level of engineering quality of GHC, and nobody used them for nearly anything, unless they were graduate students exploring surface and language semantics. But many of them just used GHC instead, too. It wasn't for lack of trying either; lots of people wanted the standard for the language to work, I used to be on the standards committee for the language. So they were useful to some extent design space. But there are many, many, many other important concerns for a "production" programming language; robust feature support, good platform support, high quality code output, robust testing regime and code review, good library and API design, high quality debugging support, package management, editor support, all kinds of stuff. These also dovetail together; certain efforts at the semantic level are nice but if they don't have a good story for debugging or something, they might not make the cut.
Really this seems like one of those requirements that's always impossible to satisfy in some sense, a kind of catch-22. If you're one of the 800lb gorilla programming languages (Java, C++, Python), you might have one or two "production" implementations and if you're lucky the ratio of usage is better than 80/20, but they exist and therefore you are a "production-ready" language. Nobody else has the money to staff engineers for multiple alternative languages (OCaml, Elixir, TypeScript, Go) despite them funding billions of dollars worth of software, so they still aren't "professional" and therefore do not qualify. I get it, and it's not for zero merit, but I think it's mostly just a cat-and-mouse game, at the end of the day.
gcc-rs existing of course has many other benefits beyond this; people know GCC so they can now have a free Rust compiler for their CPU ports, etc. This is still good. But really it's still the exception. I do think this is a good effort but I consider this sort of thing one of those basic folklore issues that's actually much more nuanced in practice.
Any time you hit a fork button on an Open Source programming language's github page, you get your own independent implementation. Hire a contractor and introduce any "extensions" you need.