Modular ABI for Rust

12

Is this the most compelling reason? I could be but I suspect that it largely depends on who you ask. In conversations that I've been in ( one of which at least was started by me, though, so not a good indicator ) it has actually been Rust<->Rust interaction that was the motivation behind the stable ABI.

Right now there isn't any way to build Rust crates that can dynamically link to other Rust crates, a practice that is extremely common with C and C++, and very useful for plugins.

I guess it doesn't really matter which is the most compelling reason I guess, but we should try to come up with a good list of all of the benefits and issues. Starting on the Pros:

Pros

  • Allows dynamically linking Rust crates to other Rust crates:
    • This allows for dynamically loaded plugins to Rust programs
    • This allows you to save compile-time/disk space for projects, for example, that have multiple CLI's that all link to the same core library crate

    • Note: This use-case potentially rather well covered by abi-stable-crates

  • Allows the potential for making libraries loadable by other languages such as swift:

    • Quote: Imho one of the biggest mistakes C++ ever made was not stabilizing its abi; swift just stabilized theirs and is already reaping the benefits, swift system libraries, the swift runtime, swift UI libraries, all dynamically linked and backwards abi compatible.

    • Quote: I’d love to use Swift ABI from Rust . extern "C" as the lowest common denominator is too low for Rust, but maybe there’s a useful subset of Rust that can be mapped to Swift’s ABI to provide useful interfaces for Rust and Swift?

  • Insert that note @isaac made earlier about OS writing by someone

Cons

  • Limits optimizations the compiler can perform
    • This would hopefully be helped if we could create a modularizable ABI. We would hope that you could like publish an ABI implementation as a crate ( I mean we're dreaming already, right, :wink: ) and then version the crate. If you ever need to break ABI compatibility for some optimization, you could do it within Semver.
  • Depending on the implementation, if we want to make ABI plugins, to avoid stabilizing the compiler's built-in ABI, we might run into another problem because we have to stabilize the plugin interface, which could be another can of worms.
  • A bunch of people could write ABI crates and it would make it really not standardized because everyone uses different ones?
  • Who knows how hard this could be...

BTW some potentially good idea for implementation in this comment.

Yep, that's the closest thing I've seen to solving this problem yet. Very cool, but requires creating interface crates to act as the middleman.

1 Like