This is a thing I've been wondering about. Is dynamic linking (in the way that C/C++ programs use it all the time) not a usecase that Rust wants to cover?

You can do dynamic linking, you just can't do it across compiler versions. This is how all of the Linux distros are doing it, for example.

It's a spectrum:

Rust: recompile the world when you update the compiler

C++: recompile the world when you change ABIs or when the ABI changes (My understanding is that MSVC++ changes the ABI every ~2 years? I could be wrong.)

C: never recompile the world

It's not that we don't want the benefits of a stable ABI, but it's a monumental task, and there are more important things for now.

Don't forget that you can get a stable ABI today by using the C ABI. You just lose out on the fancier features Rust has.

> C++: recompile the world when you change ABIs or when the ABI changes (My understanding is that MSVC++ changes the ABI every ~2 years? I could be wrong.)

This is only half true: every new release, the ABI of the runtime library changes. But the Visual C++ compiler ABI hasn't changed in decades.

If you design your own library ABIs so they don't pass std::foobars around, you can link C++ libraries built with VC++6 with ones built with the latest version, and the whole thing is going to work fine - the trick is that multiple versions of the runtime DLLs can coexist in the same process.

GCC/libstdc++ hasn't changed its ABI in more than a decade, since release 3.3 or 3.4; they even did incompatible changes to std::string in GCC 5 without breaking ABI:

https://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c...

Great, thank you for the clarification.

Starting with vs2015 microsoft promises more stable abi.

Unfortunate, but expected. On that note, would there be any breakage loading multiple Rust .so's with differing compiler/stdlib versions into the same process? This is one of my main concerns about the lack of ABI stability and the static-linking-first design of Rust. With C++ at the very least I know Red Hat isn't going to break the ABI within a major release, but the Rust 1.21 packages are already in epel-testing.

If you want to ensure that there's no breakage, the only way is to use the same version of the compiler on all the Rust code.