[simplotek]

> Having two independent implementations is good for finding code depending on compiler bugs.

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.

[411111111111111]

Thats just silly, there are a lot of production ready languages that only have one full implementation such as Typescript, Elixir etc

[tristan957]

It would be pretty hard for a second implementation of TypeScript to gain any share of the market since Microsoft refuses to update the TypeScript specification. They point to tsc and say that is the specification. It is completely unprofessional in my opinion.

[simplotek]

> (...) such as Typescript

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?

[fathyb]

swc only does transpilation, it does not support TypeScript's type-checking which is its main feature.

[dschuessler]

The author of swc is currently working on a Rust-port of the type checker: https://github.com/dudykr/stc

Here is an interview with them: https://www.totaltypescript.com/rewriting-typescript-in-rust

[lpapez]

Counterexample: the fact that there is only a single official go compiler is great advantage IMO since it enables a lot of cool tooling and great new features are introduced quickly in the official implementation.

[yencabulator]

gccgo was released in 2012.

https://go.dev/doc/install/gccgo

https://www.gnu.org/software/gcc/releases.html

[simplotek]

> since it enables a lot of cool tooling

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.

[pornel]

> What leads you to believe that the lack of alternatives leads to enabling "a lot of cool tooling"?

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.

[surajrmal]

Cargo is not universal. Many projects use rustc directly with an alternative build system such as bazel, make, or meson as they are in multilingual repos. The fact these projects exist doesn't affect your experience with rust. The fact a gcc tool chain for rust will exist should similarly not affect your experience.

[edgyquant]

Doesn’t Go also have a GCC version?

[Conan_Kudo]

It does. GCCGO is often used for bootstrapping golang, and is sometimes used as a full alternative compiler for architectures that Google refuses to consider supporting.

[aseipp]

These days lots of languages are single-team efforts, because producing high-quality production programming languages is an incredibly large amount of (difficult) work. It is really, really difficult, it takes many years, you constantly get shit on by people for everything, and if you're lucky you might get a tiny bit of money after a while. It isn't just coincidental complexity; programmers are actually incredibly demanding users with many needs. And so it isn't easy to find the money and people to perform multiple implementations, outside of very particular cases. Even the ratio of C/C++ programmers to high quality implementations that see significant production use is basically astronomical. And the unfortunate news is that alternative implementations don't often contribute very much to the overall production-language effort if they aren't of high quality or set out to achieve particular goals.

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.

[saurik]

The number of people who use those alternative implementations -- or even the quality of their output with respect to performance or platform support -- don't really matter: the reason to insist on (at least, and as unrelated as possible) two separate implementations of something is to ensure that the behavior of the language isn't merely an accident of incorrect code in the compiler instead of an intentional choice by the language designers, as it shows that two different teams came to the same result (at which point hopefully it is noticed if there are spec issues and those are either corrected in the parent compiler or "bug for bug" duplicated in the child compiler after documenting the issue in the spec). Until you have done this, it is difficult to even claim what the language even is.

[globalreset]

That's an antiquated notion from the times when programming language implementations were 99% propriety, so you needed some ability to "shop around".

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.