Rust proposal explores stable cross-crate ABI without runtime overhead

Rust has spent years making one bargain very intentionally: no stable ABI, no frozen layout promises, and maximum room for the compiler to optimize. The new RACE proposal, short for Rust Advanced Contract Enforcement, asks whether that bargain can be reworked without turning Rust into a slower or more rigid language. If the answer is yes, the payoff reaches far beyond internals talk, into plugins, kernels, and any system that needs binaries to survive version churn.

The ABI problem Rust keeps circling

Rust’s own reference is blunt about the boundary here: ABI is a property of compiled output, and `extern` plus linking choices shape it. That matters because Rust does not guarantee calling conventions and in-memory layout the way a stable binary interface would, which is exactly why the compiler can keep doing aggressive optimization work. The downside is practical and familiar to anyone building larger Rust systems: once you want separately compiled pieces to talk to each other across crate boundaries, the ground gets slippery fast.

That is why `#[repr(C)]` keeps showing up as the escape hatch. It gives you something more predictable, but at a cost: you trade away Rust’s richer type expressiveness and a chunk of its optimization freedom just to get a boundary you can trust. The RACE discussion starts from that pain point and asks whether Rust can do better than choosing between performance and stability as if they were mutually exclusive.

What RACE is trying to change

The core idea behind RACE is to move ABI resolution out of the language boundary and into link time, using a semantic linker instead of a tool that only understands raw object code. That is a subtle but important shift. Instead of freezing ABI rules directly into Rust syntax, the proposal treats binary compatibility as something a smarter build step could negotiate later, after the compiler has already done its work.

That design is what makes the proposal interesting to Rust developers who care about both speed and deployment flexibility. In theory, a semantic-linker approach could let Rust keep its optimization model intact while still producing reusable binaries that are more portable across crate boundaries. In practice, the bar is very high: the contract surface would need to be unambiguous, the allowed and forbidden crossings would need to be nailed down, and the resulting semantics would have to be precise enough to preserve Rust’s safety story.

Why the idea keeps resurfacing

This is not the first time Rust has wrestled with stable ABI. A 2020 Rust Internals discussion on a stable modular ABI argued that Rust does not standardize ABI today, and suggested that a stable ABI could enable dynamic linking between Rust crates, lower compile times, reduce disk use, and improve interoperability with languages such as Swift. That thread also captured a recurring frustration in the ecosystem: some teams had already decided that C was easier to live with, not because it was safer, but because its ABI was predictable.

RACE lands in that same long-running argument, but with a sharper question. Instead of asking Rust to freeze itself into one universal binary contract, it asks whether a more intelligent linker could let Rust keep its semantic richness and still offer a stable path between crates. That is why the debate feels bigger than just another ABI mode. It is really about whether Rust’s binary compatibility story can be built around a new layer of tooling rather than a single frozen calling convention.

The workarounds already exist, which tells you the need is real

The ecosystem has not waited around for a perfect language-level answer. The `abi_stable` crate already serves Rust-to-Rust FFI with load-time type checking, and it can load libraries built with a different Rust version than the consumer crate. Its feature set is a good reminder of how much machinery is needed just to make this space usable: `StableAbi`, `DynTrait`, prefix types, ffi-safe nonexhaustive enums, and support for plugin systems and library loading without unloading.

`stabby` was created for the same reason, explicitly as a response to the lack of ABI stability in Rust, and it treats Rust’s only stable ABI as the C ABI. That is the clearest signal in the whole discussion that the demand is not hypothetical. Users are already building layered solutions because they need plugins, long-lived binaries, and reusable components that can survive compiler upgrades and crate-version drift.

Why the current Rust roadmap makes this feel more than theoretical

The timing matters because the Rust Project Goals already include work on safe linking for separately compiled code and stable Rust for Linux. The Linux-related goal says Rust code in the kernel should build on stable Rust with an MSRV tied to an external benchmark such as Debian stable. That is a very specific kind of promise, and it only gets harder if the binary interface story remains fuzzy.

The safe-linking research goes further, saying any design should allow code compiled with different Rust compiler versions and should work for statically linked libraries, dynamically linked or loaded libraries, and plugins, with minimal assumptions about calling conventions and memory layout. That language lines up almost eerily well with what RACE is trying to probe. In other words, the proposal is not floating in isolation. It is colliding with an official effort to understand how much binary compatibility Rust can support without giving up the properties that made people choose Rust in the first place.

Where the stakes become concrete

The clearest real-world beneficiaries are the systems that live and die by modularity. Bevy describes itself as a plug-and-play game engine with an architecture that supports plugins, which makes it a natural example of why pre-compiled Rust plugins would matter. Game engines want ecosystems, not just crates, and ecosystems get a lot more useful when extensions can ship as reusable binaries instead of source-only integrations.

Rust for Linux sits on the other side of the same coin. The project exists to bring Rust into the Linux kernel, and the project goals show that stable Rust is part of the path forward. For that world, binary compatibility is not a luxury feature. It is one of the conditions that determines whether Rust can become a normal part of large, long-lived systems rather than a language that only works comfortably when everything is rebuilt together.

RACE is compelling because it tries to refuse the old tradeoff. If a semantic linker can really preserve optimization freedom while making stable cross-crate ABI practical, then Rust may finally have a path past one of its oldest missing capabilities. If not, the ecosystem will keep doing what it has already done for years: building careful, powerful workarounds and waiting for the language to catch up.