> people just statically linked most of their libraries Correction: People statically linked in other swift libraries. Particularly Swift's stdlib, which final

> people just statically linked most of their libraries Correction: People statically linked in other swift libraries. Particularly Swift's stdlib, which finally became usable dynamically circa Swift 5.5. The libraries provided by the OS at the time (UIKit, etc) were all ObjC, and they had stable ABI's (ObjC's ABI is basically string-matching on method names, so it's always had a stable ABI) and so were dynamically linked. People using UIKit from Swift were never statically linking it. > Swift is unique in that both the OS itself and all the apps are written in it This is what I'm driving at by using Rust for "foundational software". To me, foundational software means the API's the OS itself offers could be written in Rust, and could be called from Rust apps using dynamic linking. Right now if we wanted to do this, a C ABI is all we can use, which limits the utility. (Not least because all `extern "C"` in rust is implicitly tagged as unsafe.) > So it would make more sense to use an ABI that was designed from the ground up for cross-language compatibility, like crABI is trying to do (crABI was trying to do this, but it seems dead now.) Something like this would be awesome, and it's what I'm advocating for. I don't even really think we need all of Rust to be able to be used across dynamic linker boundaries... as others have pointed out, allowing enums (with associated values), Option<T> and Result<T, E>, to be passed across ABI boundaries would be a great place to start. I also agree that such an ABI doesn't have to be forced on everyone, it can be opt-in as you suggest, and used for cases where it makes sense.