3 ms·

> need multiple implementations This thinking is understandable but it’s basically pattern matching. There were two successful languages that followed this mod

> need multiple implementations This thinking is understandable but it’s basically pattern matching. There were two successful languages that followed this model and so a language that seeks to replace them should adopt the same model of design by committee followed by multiple independent implementations. But there’s no reason to think that a language needs multiple implementations to succeed. Python has had one implementation used by all its user and that hasn’t prevented from becoming a top 3 language by usage. Ditto with other very popular languages like Go, Ruby, TypeScript, C#. I don’t understand the concern that your code will stop compiling with a future version of the compiler. Firstly, Rust hasn’t broken backwards compatibility in 8 years and doesn’t plan to in future. Secondly, why do you need to upgrade the compiler? If it works on the current version you can continue to use that in perpetuity. Honestly, having multiple implementations would be a curse. I see nothing but negatives. Even the smallest proposals (like embedding data in a binary) take a decade to get buy in and 3-4 years to be implemented. Convincing everyone of the benefit of a feature is just too difficult so a lot of good ideas are never put forward, let alone implemented. And the difficulty of getting it working across compilers and operating systems. How hard is it to write C++20 code that will compile with all major compilers on all major OSs? On Rust it’s trivial. To put it simply - it’s trivial to answer the question “is this Rust code valid?” If rustc compiles it, it’s valid today and will always be valid (modulo bugs). You want alternate implementations? There’s a WIP - gcc-rs. But thankfully they haven’t forked the semantics of the language. It should and shouldn’t compile all code that rustc does and doesn’t. Otherwise it’s a bug in gcc-rs. Anything else would make the life of Rust users painful. In summary, multiple implementations is a bad idea for many reasons. If you can express the benefit beyond “that’s the way C and C++ do it”, I’m eager to listen. But please explain how Python and Go managed to succeed with one impl.

pjmlp 4y ago
C# has a ECMA standard and several implementations.
- quectophoton 4y ago
  I was surprised when I found out that Ruby is ISO/IEC 30170:2012 [1]. [1]: https://www.iso.org/standard/59579.html https://www.iso.org/standard/59579.html
Karellen 4y ago
The trouble with a single, unstandardised implementation is that it's only available on the OSs and CPUs that the lone implementation developers choose to target. By creating a standard, and allowing multiple implementations, someone creating a new OS or a new CPU architecture can create their own implementation of the language without having to wait for anyone else to deign to create the port. Maybe a new implementation won't compile very fast, or produce great code, or it might not even catch all the incorrect constructs that it ought to. But if it can make all the existing code written in that language suddenly available for the new platform, that platform instantly becomes orders of magnitude more useful and powerful. > How hard is it to write C++20 code that will compile with all major compilers on all major OSs? That depends on the code. You want to compile Firefox? You might be out of luck. You want to compile curl? Based on how portable it already is, chances are it might work out of the box once you've got a libc implementation working. You want to compile Gnu bash and coreutils, to get a basic Posix shell environment up and running? It might be a bit of work, but easier than having to reimplement a whole userland from scratch. > But please explain how Python and Go managed to succeed with one impl. It's not that the language can't succeed - at least, not on popular platforms that the devs are interested in targetting. It's that those devs get to dictate which platforms are even capable of making use of the software written in those languages. And that just rubs me the wrong way.
- pitterpatter 4y ago
  >By creating a standard, and allowing multiple implementations, someone creating a new OS or a new CPU architecture can create their own implementation of the language without having to wait for anyone else to deign to create the port. Why does that require multiple implementations? There's nothing stopping said party from adding support for their OS/arch to rustc directly today. There are multiple examples of this already: fuchsia, Sony PSP, Nintendo Switch, etc [1]. Now if you want support in rustc itself out-of-the-box this does require LLVM support your target as well. But even then, again nothing stopping you from adding LLVM support too. The avr-rust project for instance maintained an LLVM/rustc fork for a while before those patches were upstreamed. [1] See the wide variety of targets with varying support today: https://doc.rust-lang.org/nightly/rustc/platform-support.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
quectophoton 4y ago
Taking your message in good faith: I won't deny it's pattern matching, but it has less to do with what C did, and more with what history has been. I've come to distrust too much centralization on important things. Take Node.js as an example. It started controlled by a single company, then thanks to the community a Node.js Foundation was formed with an open governance model. But now that Node.js Foundation no longer exists, instead it's controlled by the OpenJS foundation, which is basically controlled by big corp. I don't want something similar to happen to Rust. That said, I don't mind Rust as it is today for user applications. And I happily use languages that have a BDFL, that are even less sound as Rust, so the problem is not Rust's success (this can't be denied). But I honestly think that if Rust wants to replace C (or even SPARK) on critical systems, and even make universities eager to teach it, it would be easier to play by the industry's rules, than to offer a "black box" ("what this compiler accepts"), for the lack of a better term. Also, as I pointed out in a different message (you might have missed it), I'm aware of gccrs, and I'm looking forward to it reaching feature parity with rustc; and I also appreciate the effort being put by the Ferrocene[1] people, because I think it with Rust getting wider adoption in the industry. [1]: https://github.com/ferrocene https://github.com/ferrocene

pjmlp 4y ago

C# has a ECMA standard and several implementations.

quectophoton 4y ago
I was surprised when I found out that Ruby is ISO/IEC 30170:2012 [1]. [1]: https://www.iso.org/standard/59579.html https://www.iso.org/standard/59579.html

Karellen 4y ago

The trouble with a single, unstandardised implementation is that it's only available on the OSs and CPUs that the lone implementation developers choose to target. By creating a standard, and allowing multiple implementations, someone creating a new OS or a new CPU architecture can create their own implementation of the language without having to wait for anyone else to deign to create the port. Maybe a new implementation won't compile very fast, or produce great code, or it might not even catch all the incorrect constructs that it ought to. But if it can make all the existing code written in that language suddenly available for the new platform, that platform instantly becomes orders of magnitude more useful and powerful. > How hard is it to write C++20 code that will compile with all major compilers on all major OSs? That depends on the code. You want to compile Firefox? You might be out of luck. You want to compile curl? Based on how portable it already is, chances are it might work out of the box once you've got a libc implementation working. You want to compile Gnu bash and coreutils, to get a basic Posix shell environment up and running? It might be a bit of work, but easier than having to reimplement a whole userland from scratch. > But please explain how Python and Go managed to succeed with one impl. It's not that the language can't succeed - at least, not on popular platforms that the devs are interested in targetting. It's that those devs get to dictate which platforms are even capable of making use of the software written in those languages. And that just rubs me the wrong way.

pitterpatter 4y ago
>By creating a standard, and allowing multiple implementations, someone creating a new OS or a new CPU architecture can create their own implementation of the language without having to wait for anyone else to deign to create the port. Why does that require multiple implementations? There's nothing stopping said party from adding support for their OS/arch to rustc directly today. There are multiple examples of this already: fuchsia, Sony PSP, Nintendo Switch, etc [1]. Now if you want support in rustc itself out-of-the-box this does require LLVM support your target as well. But even then, again nothing stopping you from adding LLVM support too. The avr-rust project for instance maintained an LLVM/rustc fork for a while before those patches were upstreamed. [1] See the wide variety of targets with varying support today: https://doc.rust-lang.org/nightly/rustc/platform-support.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm...

quectophoton 4y ago

Taking your message in good faith: I won't deny it's pattern matching, but it has less to do with what C did, and more with what history has been. I've come to distrust too much centralization on important things. Take Node.js as an example. It started controlled by a single company, then thanks to the community a Node.js Foundation was formed with an open governance model. But now that Node.js Foundation no longer exists, instead it's controlled by the OpenJS foundation, which is basically controlled by big corp. I don't want something similar to happen to Rust. That said, I don't mind Rust as it is today for user applications. And I happily use languages that have a BDFL, that are even less sound as Rust, so the problem is not Rust's success (this can't be denied). But I honestly think that if Rust wants to replace C (or even SPARK) on critical systems, and even make universities eager to teach it, it would be easier to play by the industry's rules, than to offer a "black box" ("what this compiler accepts"), for the lack of a better term. Also, as I pointed out in a different message (you might have missed it), I'm aware of gccrs, and I'm looking forward to it reaching feature parity with rustc; and I also appreciate the effort being put by the Ferrocene[1] people, because I think it with Rust getting wider adoption in the industry. [1]: https://github.com/ferrocene https://github.com/ferrocene