Hacker News Reader

Comment by steveklabnik | Hacker News Reader

I don't share your evaluations here, but a question:

  > no major OS seems to be picking up Rust as a first class citizen,

What would this mean to you?

View on HN

Yeah not really sure what that was supposed to mean in relation to Rust. To me that statement would only make sense for languages that require some sort of runtime/interpreter installed rather than natively compiled.

eg Python and Perl get shipped by default in most Linux distros base image, whereas Java or Ruby don't tend to be.

Whereas C doesn't have a compiler shipped in some/most base images - despite C being about as first class as languages get on Unix.

Yeah. I was also wondering if they meant "available through my distro's package manager", in which case, that's been happening a lot lately. Debian and Fedora will both have initial packages in their next releases, and work is ongoing with a number of linuxes.

I was composing a much longer answer before I realised that this is actually a really interesting question. While I try and think through that, this is my immediate reaction. It comes down to one thing: the ABI.

Only C (and therefore to some extent C++) is the first class citizen in all the major OS families we care about, because the C ABI is the standard for compiled objects (whether executable or library).

Totally. Rust is still far too young for something like ABI stability, so it wouldn't even make sense as an option yet. But beyond that, this pretty much puts the world in two boxes: "C" and "not C". There's a lot of activity in the "not C" space, so being there isn't an automatic death-knell for Rust, as the OP seems to imply.

> Rust is still far too young for something like ABI stability

Without question.

The interesting question to me is (if starting again) whether ABI stability/compatibility is something that is necessary or desirable for userspace citizens to interoperate with each other and the kernel.

> Only C (and therefore to some extent C++) is the first class citizen in all the major OS families we care about, because the C ABI is the standard for compiled objects (whether executable or library).

Well, on Windows there's COM for this, which is technically the C ABI too, but really deserves to be considered its own thing.

Yes, that's it. To keep things maintainable, OS interfaces are available to applications in the form of shared libraries, and that requires a well-defined and stable language ABI.

It's regrettable that C++ currently has an advantage over Rust in this regard...

C++ has no advantage over Rust in this regard : C++ and Rust does not have stable ABI. But both can use the C ABI when a stable ABI is needed.

C++ is not just boost and ICU - there are a handful of C++ libraries with a good ABI compatibility track record, for example Qt and the KDE stack.

The C++ ABI of Microsoft Visual Studio is stable since practically forever, albeit with a severe restriction: the language ABI is stable, but not the C++ (or even C) standard library ABI - every Visual Studio release comes with a new incompatible msvcrNNN.dll. But you can load as many different runtime libraries into a process as you like, the big practical restriction is that you can't pass standard library objects allocated by one runtime to a different one.

The C++ ABI of GCC is stable since version 3.2, released in 2002, on x86 platforms (there were numerous fixes in later releases for other platforms). They even managed to retrofit new incompatible C++11 requirements on std::string with some preprocessor hackery and namespace mangling, without bumping the libstdc++ SONAME.

As usual, on macOS the situation isn't as good because they threw out libstdc++ for some clang reinvention of the wheel.

It's not really true that C++ does not have an ABI advantage over Rust if (by your own comment) they both end up using the C abi. Although pedants will insist that C is not a subset of C++, practically speaking you can write idiomatic C perfectly fine that will compile with a C++ compiler, and much C code in the wild is actually written this way. And most moderately experienced C++ developers are very comfortable with all of these elements and syntax (like pointers, goto, C style callbacks, etc), because they are a subset of their own language. It's very straightforward to have your API be C (and therefore have a stable ABI) but do implementation in C++. Even some C standard libraries do this.

In summary, if you're writing a C API/ABI, source compatibility is still a major advantage, there is no two ways around it.

Only barely though, C++ is still notoriously hard to link to.

Reply on news.ycombinator.com