4 ms·

For Rust to become the go-to systems programming language, it has to beat C. But Rust lacks C's biggest advantage: portability. Pretty much every architecture

by Seirdy 5y ago

For Rust to become the go-to systems programming language, it has to beat C. But Rust lacks C's biggest advantage: portability. Pretty much every architecture and OS out there has a C compiler. Rust only works well on the most mainstream systems: Linux, macOS, Windows; x86(_64), ARMv8. Building nontrivial Rust programs on the BSDs and other architectures is really difficult. Python recently broke the CI for many distros after depending on a Rust package for this reason. There are three overlapping reasons for Rust's lack of portability: 1. Language complexity makes it hard to develop a new target or compiler. 2. Language development speed is high, so maintainers of other implementations need to keep up their pace. 3. The language is implementation-driven rather than spec-driven. rustc is the source of truth rather than a specification. Developing and maintaining a new Rust target/compiler is a ton of work compared to doing the same for C, Go, or even D. The OpenBSD, Plan 9 (!!), and initial Windows targets for Go were all community efforts without Google funding. Alternative platforms are less used partly because they lack some popular software. We don't need to make it harder than it already is to use them. As long as the aforementioned three issues exist, Rust won't (and shouldn't) be a C replacement. I do see a place for Rust on the server, for performance-sensitive bits of software that's written mostly in higher-level langs. My side of the "keep other architectures alive" battle has pretty much lost there. Making alternatives to ubiquitous tools like grep (ripgrep) or sed (sd) is also fine, since these alternatives won't replace their predecessors. But I hope it doesn't become a de-facto for desktop/end-user software. PowerPC computers shouldn't become e-waste if they aren't broken, and switching to different architectures shouldn't be as big a deal as it currently is.

alerighi 5y ago
Rust developers seems to assume that the only compilation target is x86 or ARM with POSIX API or Windows, or less often whatever architecture is supported by LLVM. And the rest? There are a ton of architectures that are not ARM, one example is the popular chip ESP32 that uses a proprietary architecture called Xtensa. Another thing is ABI, even if something is ARM, it doesn't mean that its build process is straight forward and you can just compile with LLVM and it works. Try to integrate the SDK of some microcontrollers based on proprietary compilers like IAR, Keil, etc. It's not trivial. Possible in the end, if you want to rewrite all the linker scripts and make sure to build the executable file in the same way, just not practical. Then there are 8 bit microcontrollers, and yes you can buy an ESP32 for a ridiculous price, but what if you need to do something low power? C is universal. Nowadays you can assume that everything that has some sort of processor has a C compiler. With Rust is not like that, and probably never will, since the language is too complex to implement on low cost/low power hardware, and too high level for things that needs a low level access to the hardware.
mlindner 5y ago
Portability doesn't matter anymore. I don't know why C people press this issue so much. The world runs on x86 and ARM, with a smattering of PowerPC. Rust is already being used in embedded applications quite a bit in many companies as well. The fact that C works on IBM System 360 doesn't help anyone.
- dralley 5y ago
  Mainframes still power far more (and more critical) infrastructure than you would expect.
  - dralley 5y ago
    (But, to be fair - s360 is quite dead at this point, and Rust supports s390x fine, even if not as a tier-1 platform. Anyone who claims that C compilers support every platform equally is a liar anyway, Rust just makes the support tiers explicit).
  - mlindner 5y ago
    Sure they do, but those are places where new development is not happening, only sustaining. Rust wouldn't go into those places even if it did support those hardware.
- Seirdy 5y ago
  1. The reason why things have moved to a bit of a monoculture is because of a lack of portability in software. 2. People have PowerPC and ARMv7 devices that work perfectly well. People shouldn't have to buy a new device every N years. 3. I also described how Rust doesn't target many operating systems either; it only targets the three mainstream ones. Also, from the comment you replied to: > Alternative platforms are less used partly because they lack some popular software. We don't need to make it harder than it already is to use them.
pornel 5y ago
Approximately nobody is using Plan 9 or Itanium. Apart from nerd cred, they don't matter for Rust's future. People can keep using C for the weird DSPs that don't have 8-bit bytes. Besides, there's already a compile-to-C implementation of Rust (mrustc), and a GCC-based implementations in progress (both front-end and back-end). OTOH Rust and its tooling are way better than the C ecosystem in supporting both Windows and Unix flavors in the same codebase, in a practical manner. C prides itself in theoretical support for obsolete and niche platforms, but requires a mess of ifdefs for basic things like opening a file with non-ASCII characters (and when C programs don't work on Windows, this is dismissed as Windows' problem, not C failing to actually have the standardization and portability it claims). For a lot of programs "cargo build" just works out of the box on every Rust-supported platform. That's smoother than battling autotools, or cmake build scripts that can't find packages for inexplicable reasons, and random breakages due to C compilers/OSes having functions defined in slightly different headers, with their own quirks. Rust is really good at abstracting these pains away, so while it can't support Plan 9, it can easily support Windows. Can you imagine opening a TCP socket without needing to know about winsock idiosyncrasies?
- Seirdy 5y ago
  You seem really fixated on Plan 9. I merely used it as an example to show how even ultra-niche operating systems have support, demonstrating how adding a target need not be a monumental task. Other operating systems like FreeBSD, NetBSD, Solaris, OpenBSD, and DragonflyBSD also exist. FreeBSD is quite relevant and NetBSD and OpenBSD fill almost-empty yet significant niches.

by Seirdy 5y ago

alerighi 5y ago

Rust developers seems to assume that the only compilation target is x86 or ARM with POSIX API or Windows, or less often whatever architecture is supported by LLVM. And the rest? There are a ton of architectures that are not ARM, one example is the popular chip ESP32 that uses a proprietary architecture called Xtensa. Another thing is ABI, even if something is ARM, it doesn't mean that its build process is straight forward and you can just compile with LLVM and it works. Try to integrate the SDK of some microcontrollers based on proprietary compilers like IAR, Keil, etc. It's not trivial. Possible in the end, if you want to rewrite all the linker scripts and make sure to build the executable file in the same way, just not practical. Then there are 8 bit microcontrollers, and yes you can buy an ESP32 for a ridiculous price, but what if you need to do something low power? C is universal. Nowadays you can assume that everything that has some sort of processor has a C compiler. With Rust is not like that, and probably never will, since the language is too complex to implement on low cost/low power hardware, and too high level for things that needs a low level access to the hardware.

mlindner 5y ago

Portability doesn't matter anymore. I don't know why C people press this issue so much. The world runs on x86 and ARM, with a smattering of PowerPC. Rust is already being used in embedded applications quite a bit in many companies as well. The fact that C works on IBM System 360 doesn't help anyone.

dralley 5y ago
Mainframes still power far more (and more critical) infrastructure than you would expect.
- dralley 5y ago
  (But, to be fair - s360 is quite dead at this point, and Rust supports s390x fine, even if not as a tier-1 platform. Anyone who claims that C compilers support every platform equally is a liar anyway, Rust just makes the support tiers explicit).
- mlindner 5y ago
  Sure they do, but those are places where new development is not happening, only sustaining. Rust wouldn't go into those places even if it did support those hardware.
Seirdy 5y ago
1. The reason why things have moved to a bit of a monoculture is because of a lack of portability in software. 2. People have PowerPC and ARMv7 devices that work perfectly well. People shouldn't have to buy a new device every N years. 3. I also described how Rust doesn't target many operating systems either; it only targets the three mainstream ones. Also, from the comment you replied to: > Alternative platforms are less used partly because they lack some popular software. We don't need to make it harder than it already is to use them.

pornel 5y ago

Approximately nobody is using Plan 9 or Itanium. Apart from nerd cred, they don't matter for Rust's future. People can keep using C for the weird DSPs that don't have 8-bit bytes. Besides, there's already a compile-to-C implementation of Rust (mrustc), and a GCC-based implementations in progress (both front-end and back-end). OTOH Rust and its tooling are way better than the C ecosystem in supporting both Windows and Unix flavors in the same codebase, in a practical manner. C prides itself in theoretical support for obsolete and niche platforms, but requires a mess of ifdefs for basic things like opening a file with non-ASCII characters (and when C programs don't work on Windows, this is dismissed as Windows' problem, not C failing to actually have the standardization and portability it claims). For a lot of programs "cargo build" just works out of the box on every Rust-supported platform. That's smoother than battling autotools, or cmake build scripts that can't find packages for inexplicable reasons, and random breakages due to C compilers/OSes having functions defined in slightly different headers, with their own quirks. Rust is really good at abstracting these pains away, so while it can't support Plan 9, it can easily support Windows. Can you imagine opening a TCP socket without needing to know about winsock idiosyncrasies?

Seirdy 5y ago
You seem really fixated on Plan 9. I merely used it as an example to show how even ultra-niche operating systems have support, demonstrating how adding a target need not be a monumental task. Other operating systems like FreeBSD, NetBSD, Solaris, OpenBSD, and DragonflyBSD also exist. FreeBSD is quite relevant and NetBSD and OpenBSD fill almost-empty yet significant niches.