Item — HN Reader

C++ ABI stability is the main reason improvements to the language get rejected.

You cannot change anything that would affect the class layout of something in the STL. For templated functions where the implementation is in the header, ODR means you can't add optimizations later on.

Maybe this was OK in the 90s when companies deleted the source code and laid off the programmers once the software was done, but it's not a feature Rust should ever support or guarantee.

The "stable ABI" is C functions and nothing else for a very good reason.

4 comments

I think if Rust wants to evolve even more aggressively than C++ evolves, then that is a chasm that needs to be crossed.

In lots of domains, having a language that doesn't change very much, or that only changes very carefully with backcompat being taken super seriously, is more important than the memory safety guarantees Rust offers.

In my view, this is a good thing.

As a C++ developer, I regularly deal with people that think creating a compiled object file and throwing away the source code is acceptable, or decide to hide source code for "security" while distributing object files. This makes my life hell.

Rust preventing this makes my life so much better.

Rust does not prevent you from creating a library that exports a C/C++ interface. It's indistinguishable from a C or C++ library, except that it's written in Rust. cbindgen will even generate proper C header files out of the box, that Rust can then consume via bindgen.

> As a C++ developer, I regularly deal with people that think creating a compiled object file and throwing away the source code is acceptable, or decide to hide source code for "security" while distributing object files. This makes my life hell.

I mean yeah that's bad.

> Rust preventing this makes my life so much better.

I'm talking about a different issue, which is: how do you create software that's in the billions of lines of code in scale. That's the scale of desktop OSes. Probably also the scale of some other things too.

At that scale, you can't just give everyone the source and tell them to do a world compile. Stable ABIs fix that. Also, you can't coordinate between all of the people involved other than via stable ABIs. So stable ABIs save both individual build time and reduce cognitive load.

This is true even and especially if everyone has access to everyone else's source code

> At that scale, you can't just give everyone the source and tell them to do a world compile. Stable ABIs fix that. Also, you can't coordinate between all of the people involved other than via stable ABIs. So stable ABIs save both individual build time and reduce cognitive load.

Rust supports ABI compatibility if everyone is on the same compiler version.

That means you can have a distributed caching architecture for your billion line monorepo where everyone can compile world at all times because they share artifacts. Google pioneered this for C++ and doesn't need to care about ABI as a result.

What Rust does not support is a team deciding they don't want to upgrade their toolchains and still interoperate with those that do. Or random copy and pasting of `.so` files you don't know the provenance of. Everyone must be in sync.

In my opinion, this is a reasonable constraint. It allows Rust to swap out HashMap implementations. In contrast, C++ map types are terrible for performance because they cannot be updated for stability reasons.

My understanding: Even if everyone uses the same toolchain, but someone changes the code for a module and recompiles, then you're in UB land unless everyone who depends on that recompiles

Am I wrong?

If your key is a hash of the code and its dependencies, for a given toolchain and target, then any change to the code, its dependencies, the toolchain or target will result in a new key unique to that configuration. Though I am not familiar with these distributed caching systems so I could be overlooking something.

That's not the issue I'm worried about

> At that scale, you can't just give everyone the source and tell them to do a world compile.

Firstly, of course you could.

Secondly, you don't even need to, as NixOS shows.

C++ is still changing quite a lot though, just not in ways that fix the existing issues (often because doing so would break ABI stability).

That is a reason why a lot of folks stick with C.

In some sense, the chasm I'm describing hasn't been crossed by C++ yet

I'm not sure I'm following, are you claiming that C++ is still not widely used enough? That doesn't seem to be the case.

Except as you well know, C might not change as fast, but it does change, including the OS ABI.

Those folks think it doesn't.

> Except as you well know, C might not change as fast, but it does change, including the OS ABI.

I don't know that.

Here's what I know: the most successful OSes have stable OS ABIs. And their market share is positively correlated with the stability of their ABIs.

Most widely used: Windows, which has a famously stable OS ABI. (If you wanted to be contrarian you could say that it doesn't because the kernel ABI is not stable, but that misses the point - on Windows you program against userland ABIs provided by DLLs, which are remarkably stable.)

Second place: macOS, which maintains ABI stability with some sunsetting of old CPU targets. But release to release the ABI provides solid stability at the framework level, and used to also provide stability at the kernel ABI level (not sure if that's still true - but see above, the important thing is userland framework ABI stability at the end of the day).

Third place: Linux, which maintains excellent kernel ABI stability. Linux has the stablest kernel ABI right now AFAIK. And in userland, glibc has been investing heavily in ABI stability; it's stable enough now that in practice you could ship a binary that dynlinks to glibc and expect it to work on many different Linuxes today and in the future.

So it would seem that OS ABIs are stable in those OSes that are successful.

Speaking of Windows alone, there are the various calling conventions (pascal, stdcall, cdecl), 16, 32, 64 bits, x86, ARM, ARM64EC, DLLs, COM in-proc and ext-proc, WinRT within Win32 and UWP.

Leaving aside the platforms it no longer supports.

So there are some changes to account for depending on the deployment scenario.

The most stable would be FreeBSD with compaNx libraries/modules for old binaries, where N = FreeBSD version number.

Isn’t this solution solved by just compiling your libraries with your main app code? Computers are fast enough that this shouldn’t be a huge issue.

This assumes a lot:

- the same entity has access to the source of both the library and the main app

- library and main app share the same build tooling

And even if that’s the case, you have the problem of end users accidentally using different versions of the main app and the library and getting unexpected UB.

I think it's the domains that need to evolve, because the effects of that approach have been very bad for a very long time already

In what way rust needs to evolve? It seems pretty evolved to me already but I’m no language expert

What's the stat of single-compiler version ABI? I mean - if the compiler guaranteed that for the same version of the compiler the ABI can work, we could potentially use dynamic linking for a lot of things (speed up iterative development) without committing to any long term stable API or going through C ABI for everything.

I think the way to fix this is:

1. Have the stable ABI be opt-in similarly to how the C ABI is opt-in in Rust (`#[repr(stable)]` or similar)

2. Have the stable ABI be versioned. So it would actually be `#[repr(stable_2026)]` or whatever

The big question is does Rust want to play being adopted by those vendors, or it would leave them alone with languages that embrace native libraries.