5 ms·

> 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 implem

> 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 4y ago
Thats just silly, there are a lot of production ready languages that only have one full implementation such as Typescript, Elixir etc
- deleted 4y ago
  [deleted]
- tristan957 4y ago
  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 4y ago
  > (...) 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/ 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?
  - hejaodbsidndbd 4y ago
  - fathyb 4y ago
    swc only does transpilation, it does not support TypeScript's type-checking which is its main feature.
    - dschuessler 4y ago
      The author of swc is currently working on a Rust-port of the type checker: https://github.com/dudykr/stc https://github.com/dudykr/stc Here is an interview with them: https://www.totaltypescript.com/rewriting-typescript-in-rust https://www.totaltypescript.com/rewriting-typescript-in-rust
lpapez 4y ago
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.
- edgyquant 4y ago
  Doesn’t Go also have a GCC version?
  - Conan_Kudo 4y ago
    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.
- simplotek 4y ago
  > 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 4y ago
    > 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 https://docs.rs), IDE support, etc. (https://lib.rs/development-tools/cargo-plugins 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.
aseipp 4y ago
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.
globalreset 4y ago
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.

411111111111111 4y ago

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

deleted 4y ago
[deleted]
tristan957 4y ago
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 4y ago
> (...) 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/ 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?
- hejaodbsidndbd 4y ago
- fathyb 4y ago
  swc only does transpilation, it does not support TypeScript's type-checking which is its main feature.
  - dschuessler 4y ago
    The author of swc is currently working on a Rust-port of the type checker: https://github.com/dudykr/stc https://github.com/dudykr/stc Here is an interview with them: https://www.totaltypescript.com/rewriting-typescript-in-rust https://www.totaltypescript.com/rewriting-typescript-in-rust

lpapez 4y ago

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.

edgyquant 4y ago
Doesn’t Go also have a GCC version?
- Conan_Kudo 4y ago
  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.
simplotek 4y ago
> 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 4y ago
  > 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 https://docs.rs), IDE support, etc. (https://lib.rs/development-tools/cargo-plugins 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.

aseipp 4y ago

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.

globalreset 4y ago

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.