Comment by o11c
1 year ago
Yet, the whole crate model giving up on ABI stability as a goal hurts a lot, both for performance and for sanity.
Why aren't people designing modern languages to make it easier to keep a stable ABI, rather than giving up entirely?
ABI stability is one of those things that seems obvious ("sane"), until you try to implement ABI-stable unboxed generics and discover that the amount of complexity you incur, as well as the performance tax, is absurd. The code bloat with the resulting "intensional type analysis" actually makes the compile time worse (and the runtime far worse) than just specializing generics in many cases.
The Swift folks seem to manage just fine.
The amount of complexity that Swift has to deal with in order to make ABI stability work is exactly what I'm talking about. It's astronomical. Furthermore, it's only partial: there are some generics in which they couldn't afford the price of ABI stability, so they're marked inline and aren't ABI stable.
I like Aria's writing about this https://faultlore.com/blah/swift-abi/.
In this case (i.e. Rust specifically) what do unboxed generics mean. Without actually knowing Rust I don’t think I can analogize to either type theory or another language. I assume if I can figure out what they are I infer why they are difficult to compile.
It means ABI-stable interfaces (i.e. interfaces between separately-compiled "crates"/libraries, including dylibs and shared objects) can involve arbitrarily complex types with possibly nested generics, and these are implemented behind a single pointer dereference at most. This requires something a lot like dyn trait object vtables in Rust ("witness tables") except quite a bit more complex.