3 ms·

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 targe

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...
- Karellen 4y ago
  Off the top of my head? Maybe you want to target a small system with a native compiler, so users of those systems don't have to cross-compile, but the standard implementation is just too big to run on those systems? (e.g. tcc) Or maybe you don't want your work to be redistributed under the original project's license, and would prefer to have a copyleft/permissive/proprietary licensed version instead, which can still call itself a "real" implementation. (e.g. mono or gcj/openjdk. Or gcc, originally.)
nindalf 4y ago
> It's that those devs get to dictate which platforms are even capable of making use of the software written in those languages. Adding other tiers is welcomed. Take a look at the supported platforms (https://doc.rust-lang.org/nightly/rustc/platform-support.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm...) and see if there's a platform you'd like to target that isn't a tier 3 target at least. There's HaikuOS, PlayStation1 etc. I'm on a Tier 2 platform myself and I'm really happy. If you'd like even more platforms, there's an ongoing project to add a GCC backend to rustc (https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-20 https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-20). > 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. I agree with this, but creating a front end that can actually compile all existing code correctly is a massive task. If the compiler is modular enough, you should be able to contribute just a backend, rather than reimplementing a frontend. I'm strongly against only the frontend reimplementation, because it's no longer clear what "valid" Rust code is. In summary - I completely agree with the importance of targeting niche platforms. I think supporting multiple backends (LLVM now, libgccjit and Cranelift in future) gets us there without fracturing the ecosystem. > but easier than having to reimplement a whole userland from scratch. Probably. But once it's reimplemented (https://github.com/uutils/coreutils https://github.com/uutils/coreutils) I think it's really cool you can run get binaries for Linux, macOS and Windows with one build command.

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

Karellen 4y ago
Off the top of my head? Maybe you want to target a small system with a native compiler, so users of those systems don't have to cross-compile, but the standard implementation is just too big to run on those systems? (e.g. tcc) Or maybe you don't want your work to be redistributed under the original project's license, and would prefer to have a copyleft/permissive/proprietary licensed version instead, which can still call itself a "real" implementation. (e.g. mono or gcj/openjdk. Or gcc, originally.)

nindalf 4y ago

> It's that those devs get to dictate which platforms are even capable of making use of the software written in those languages. Adding other tiers is welcomed. Take a look at the supported platforms (https://doc.rust-lang.org/nightly/rustc/platform-support.html https://doc.rust-lang.org/nightly/rustc/platform-support.htm...) and see if there's a platform you'd like to target that isn't a tier 3 target at least. There's HaikuOS, PlayStation1 etc. I'm on a Tier 2 platform myself and I'm really happy. If you'd like even more platforms, there's an ongoing project to add a GCC backend to rustc (https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-20 https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-20). > 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. I agree with this, but creating a front end that can actually compile all existing code correctly is a massive task. If the compiler is modular enough, you should be able to contribute just a backend, rather than reimplementing a frontend. I'm strongly against only the frontend reimplementation, because it's no longer clear what "valid" Rust code is. In summary - I completely agree with the importance of targeting niche platforms. I think supporting multiple backends (LLVM now, libgccjit and Cranelift in future) gets us there without fracturing the ecosystem. > but easier than having to reimplement a whole userland from scratch. Probably. But once it's reimplemented (https://github.com/uutils/coreutils https://github.com/uutils/coreutils) I think it's really cool you can run get binaries for Linux, macOS and Windows with one build command.