[fredmorcos]

I don't want to be defending Rust but your post has so many misconceptions. May I ask where you got all that information and what your background is?

> C++ at least has extern "C" going for it, which disables name mangling. Rust doesn't have that, nor does it have a stable ABI.

Rust has #[no_mangle] and extern "C" and those two guarantee that ABI stability you're looking for.

> Then furthermore, a vast amount of effort has been put into these tools over the last years to ensure that they run on any *nix and any architecture, and even so they can be ported with relative ease.

That's actually a breeze in Rust, including cross-compilation (which is relatively painful in C/C++).

> For example, how do you suggest implementing glibc in Rust? You might argue "why would we need the C standard library when we're porting things to Rust", and the answer is that if you want to make a move towards rust, having a C library (particularly the GNU one, a lot of software depends on GNU extensions) is of utmost importance until that goal has been achieved.

There's work towards that: https://gitlab.redox-os.org/redox-os/relibc

[gammagoblin]

>I don't want to be defending Rust but your post has so many misconceptions. May I ask where you got all that information and what your background is?

I am primarily a systems programmer and write software for the petroleum industry in my country. I work with C++ and in some (rare) cases C, and I've been doing that for the past 4 years. I have my own WIP hobby unix-like microkernel project written in C as well.

>Rust has #[no_mangle] and extern "C" and those two guarantee that ABI stability you're looking for.

I admittedly did not know this before it was pointed out to me.

>That's actually a breeze in Rust, including cross-compilation (which is relatively painful in C/C++).

It really isn't. Have you looked at rustc's compiler targets? It's not a very long list. Support is improving, but there's still a lot of key areas that are completely missing. To my knowledge it supports x86, ARM, MIPS and POWER. That's not a long list.

>There's work towards that: https://gitlab.redox-os.org/redox-os/relibc

That's good, and is genuinely what's necessary to put Rust in key components.

[comex]

Based on [1], also full support for s390x (IBM mainframes), as well as support for SPARC, WebAssembly, and asm.js as targets only (you can't run rustc itself on them, but can cross-compile to them). RISC-V support was recently merged into master (not sure why it's not on that page). AVR and m68k (seriously) both have actively developed ports which are living in forks until they're ready to be merged.

Anyway, most of the work of porting Rust to new platforms is not in rustc itself, but rather porting LLVM to target that platform. This is bad in a way and good in a way. It's true that LLVM doesn't have as extensive a list of supported targets as GCC. However, for people developing new architectures and OSes, LLVM is often the go-to choice as the first compiler to port. For example, WebAssembly, eBPF, and AMDGPU are all supported in upstream LLVM at present, but not in GCC. On the other hand, RISC-V got GCC support first – but lowRISC also actively developed an LLVM backend, which is now upstream. [2]

Of course, C benefits from having multiple implementations; even on platforms that only LLVM has a backend for, you can just use LLVM's C compiler (Clang), whereas there's (currently) no Rust compiler with a GCC backend. I'd love to see that change in the future. Still, I'd say Rust target support is already pretty strong when it comes to the (embedded) platforms most people are doing new development for, and rapidly getting stronger.

[1] https://forge.rust-lang.org/platform-support.html

[2] https://www.lowrisc.org/llvm/status/

[steveklabnik]

It’s not on that page for the simplest reason in open source: nobody sent in a PR.

I’ll look into it tomorrow, thanks.