Hacker News Reader

Are Rust ABIs even guaranteed to be stable for a given compiler version and library features? ie. doesn't the compiler allow itself to change the ABI based on external factors, like how other dependents use it?

View on HN

The Rust ABI is unstable, but is consistent within a single Rust version when a crate is built with `dylib` as its type. So Debian could build shared libraries for various crates, but at the cost of a lot of shared library use in a less common/ergonomic configuration for consumers.

The thing is that even `dylib` is just not very useful given the extent that monomorphized generic code is used in Rust "library" crates. You end up having to generate your binary code at the application level anyway, when all your generic types and functions are finally instantiated with their proper types. Which is also why it's similarly not sensible to split out a C-compatible API/ABI from just any random Rust library crate, which would otherwise be the "proper" solution here (avoiding the need to rebuild-the-world whenever the system rustc compiler changes).

Microsoft's MFC, Borland/Embarcadero C++ OWL/VCL/FireMonkey, Qt libraries with dynamic linking and templates, as an example,

Swift stable ABI is another.

It is a matter of priorities where to invest developer resources and tooling.

Yep, all true.

Reply on news.ycombinator.com