¹https://github.com/rust-lang/rust/tree/master/compiler/rustc...
Having two independent implementations is good for finding code depending on compiler bugs. The development will also highlight where the Rust language is not documented/specified enough yet.
The GCC implementation may end up with a different design, and perhaps faster compile times, or at least we'll know whether Rust is inherently slow to compile, or is that just rustc. Rustc supporting multiple back-ends can't have as close integration with GCC's back-end as GCC's own front-end.
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.
I think that's what the parent was replying to, not somehow claiming C/C++ people are insignificant.
Micropython can be counted as 0.25 or something :)
I will admit to not being familiar enough with Ruby to say anything about that
This comment is so blatantly wrong and detached from reality that it makes me wonder if it's just a good old fashioned troll.
You'd be hard-pressed to find any production programming language which does not have multiple independent implementations.
‶Toys″ like Go, OCaml, arguably Ruby & PHP, Perl, Erlang, Kotlin, ...
PHP has alternative VMs and specialized servers for serving it fast and in encrypted manner (they are closed sourced), tho.
Kotlin runs on JVM, which has at least three fully compliant implementations.
Erlang is a specialized language and telecommunications platform. It’s something different.
Well, if they are not public, it does not really have any influence on language specification.
> Kotlin runs on JVM, which has at least three fully compliant implementations.
And Rust runs on x86 which has myriad of implementations; still, we're talking about the language compiler, not the underlying runtime.
> Erlang is a specialized language and telecommunications platform. It’s something different.
How so? It's a language built over a runtime, just like Java. I don't see how the specifics of the runtime have to do with anything.
TruffleRuby is a thing, as is JRuby.
Implementing Erlang without implementing its VM and the whole infrastructure, which is a much larger task than merely a VM like Python's.
Any single-implementation language inevitably degrades to the point where the implementation becomes the specification. Shortly afterwards, people can only use the language if their tool chain, operating system, etc. closely match the understanding of the language authors. That's a bad situation to be in.
> Shortly afterwards, people can only use the language if their tool chain, operating system, etc. closely match the understanding of the language authors.
Perl, well-known for being an iffy language to install and running on a restricted set of OS/architectures.
[1] The good reasons, anyway. Please no GPL screaming.
[2] Something that IMHO rust has historically been kinda bad at. Even now there remains no clear specification I can find that explains exactly what behavior the borrow checker will admit vs. reject.
How is “we want a toolchain we can use as an library from non-GPL code” not a good reason?
The ability to link against LLVM and Clang has driven a massive advance in languages and tooling.