While I am on the Rust side on this, I am not sold out on mixing crates with different editions, because I believe it won't work at scale in typical enterprise contexts.
Meaning, having binary crates compiled with different epochs, and then passing data and closures across crate public functions, specially using as input data from modern ones into the older ones.
With the language evolution it won't be possible to keep semantic changes to work as expected, or if the runtime requirements have changed, that linking everything together will still work as expected.
To me epochs seem to only work when using a single compiler, compiling all crates from scratch, with is nice, but not what enterprise C, C++, Java, .NET code looks like, and any new language being adopted is expected to play the same game.
Hence why Apple took such a big effort to make Swift ABI being able to deal with language updates.
If future Rust versions do make semantic changes to existing language constructs, that will presumably only apply to crates built with the new edition, and crates built with the old will get the old semantics.
If weβre talking ABI-level stuff, that doesnβt require an edition because you build all your crates with the same compiler, so it can use a consistent ABI.
Swiftβs ABI stability has nothing to do with semantic changes and everything to do with they wanted binary compatibility, so they could start using Swift in the system frameworks that your app links against.
Rust will never be an option in certain scenarios if the only option is to be like a scripting language and require its users to compile everything from source code.
Swift's ABI also takes into account ways to secure the ABI while evolving the language.
If you want languages that introduce semantic changes and break your code, you have many options to pick from, C++ being one such language in the same space as Rust.
Meaning, having binary crates compiled with different epochs, and then passing data and closures across crate public functions, specially using as input data from modern ones into the older ones.
With the language evolution it won't be possible to keep semantic changes to work as expected, or if the runtime requirements have changed, that linking everything together will still work as expected.
To me epochs seem to only work when using a single compiler, compiling all crates from scratch, with is nice, but not what enterprise C, C++, Java, .NET code looks like, and any new language being adopted is expected to play the same game.
Hence why Apple took such a big effort to make Swift ABI being able to deal with language updates.