Before Swift Evolution, I had no idea what an ABI was. Today, even though I still get lost when it comes to the minutiae, I can at least follow along threads like this one without feeling too uncomfortable.
It’s also eye-opening to see how different communities and companies prioritize different aspects of a programming language. Rust got async/await since version 1.39.0, released last November, but they have yet to stabilize the ABI. Apple went about it the other way around with Swift, given the importance of ABI stability for their platforms.
A stable ABI would allow Rust libraries to be loaded by other languages (such as Swift), and would allow Rust to interop with libraries defined in other programming languages. […] However, a stable ABI is not all peaches and roses. Having to standardize the memory layout of data can limit the number of optimizations the compiler can perform.
A modularized ABI would be optional while compiling. This modular ABI could be published as a versioned crate. If the ABI ever needs a backward-compatibility breaking change, the change could be made within Semver. Alternatively, a new ABI-compliant compiler backend could be developed, or the current compiler backend could be extended to support an ABI feature flag that would toggle ABI compliant builds.