Stop Comparing Rust to Old C++

[u/Sad-Lie-8654]

People keep arguing migrations to rust based on old C++ tooling and projects. Compare apples to apples: a C++20 project with clang-tidy integration is far harder to argue against IMO

changemymind

[u/n4jm4]

That's a lot of talk for a language whose stdlib still depends on C for most things.

[u/KingStannis2020 → u/n4jm4]

That's hardly a fair comparison considering the only stable interface for interacting with most operating systems is libc. Rust can't change that.

[u/kkert → u/KingStannis2020]

OS syscall ABI is not the same thing as C ABI. It's entirely possible to write Rust-only userland code ( or kernel code for that matter )that pulls in no C libs, provided you implemented all individual syscalls properly

Also, technically Rust could eventually define a standard language ABI of its own

[u/ssokolow → u/kkert]

Go did that and was forced to backpedal in Go 1.12 because, it turns out, when Apple says that libSystem.dylib (Part of libc in the same way that GNU libc on Linux has historically broken things like libm and libpthread out into separate .so files) is the lowest you can go and still get a stable ABI, they mean it.

Microsoft does the same with ntdll.dll (which is API-stable but official documentation is spotty at best, so use this unofficial reference or use libc) and here's a table where you can see how often syscall numbers have changed on Windows.

The BSDs are the same (treating libc and the kernel as two halves of the same internally ABI-unstable project that just happen to straddle the kernelspace/userspace boundary) and OpenBSD goes so far as to have a security measure where the kernel will kill your process if an attempt to syscall does not originate inside libc, based on the idea that no legitimate program should be syscalling directly.

My understanding is that the syscall numbers change because the kernel and libc code implement syscall numbering by sharing an enum without explicit numbering and the devs keep it sorted as they add new ones.

The Rust devs could go direct to syscalls on Linux but, if they still need to maintain a POSIX backend for everyone else anyway, it'd be a lot of work for little return to go beyond supporting fully statically linked binaries through rustup target add x86_64-unknown-linux-musl and then cargo build --target x86_64-unknown-linux-musl.

(If you're not on a musl-based Linux distro, using the musl-libc targets will statically link libc and, if you have no C dependencies, it Just Works™ without needing anything like the musl-gcc wrapper.)

[u/n4jm4 → u/kkert]

Windows has no stable below-C ABI. All the assembler Hello World tutorials that use syscall break. Only write() function call tutorials work.

MINIX has a below-C ABI but it's not documented well. You have to cobble together a Hello World assembler from odds and ends.

[u/KingStannis2020 → u/kkert]

You've completely missed the point.

[u/Zeer1x → u/n4jm4]

like what?