3 ms·

Rust isn't against shared libraries per se, but it doesn't have a stable ABI. ABI for a language with generics is a very tricky problem, and there's no solution

by pornel 6y ago

Rust isn't against shared libraries per se, but it doesn't have a stable ABI. ABI for a language with generics is a very tricky problem, and there's no solution on the horizon yet. As for LTS, there is indeed a stand-off with Linux distros. Rust bets on Chrome's update model, where updates are small and backwards-compatible, so everyone is on the latest, and versions don't matter. Linux distros want Rust to have Internet Explorer update model where there are only updates every X months or years, and developers have to specifically test and work around to support multiple old versions. Note that Editions aren't language versions. They're like "use strict" in JS. They only toggle warnings and small parsing details, but there's only one Rust version. Every Rust edition can use any Rust feature, as long as it parses. For example, everything new added in 2020 is available in the Rust 2015 edition.

Luker88 6y ago
> Rust isn't against shared libraries per se, but it doesn't have a stable ABI. I'd like to point out that this effectively means "it's not against shared libs, but it will actively ignore anything needed to work with them" The "move fast and break things" is fine, as long as you are the last link in the chain. Rust is the first. > ...there's only one Rust version. Every Rust edition can use any Rust feature, as long as it parses. For example, everything new added in 2020 is available in the Rust 2015 edition. IMHO this is a great feature...for the last link in the chain, not the first. Note how this is only possible since for now there is only one rust compiler. As soon as GCC or others get ready, how do we sync between features supported? IMHO eventually the "editions" will be treated as minimum version to compile with. Also, as more and more software is written in rust, lack of lts will force the users to update whole systems every 2 months (and making dynamic linking impossible will only worsen things). I still get 30Mb/s flat connections, and even with that multi-GB updates are a pain. Now imagine that for countries that are worse off. It's not impossible to work with, it just makes a lot of management things a constant (small?) pain that we had eliminated before.
- nicoburns 6y ago
  > I'd like to point out that this effectively means "it's not against shared libs, but it will actively ignore anything needed to work with them" There are libraries that enable this: https://docs.rs/abi_stable/0.9.3/abi_stable/ https://docs.rs/abi_stable/0.9.3/abi_stable/
  - Luker88 6y ago
    Well, we can all agree that the solution should not be "we'll just require everyone to change all their code through this library" static vs dynamic is a linker (and LTO) problem, we can't start asking everyone everywhere to change all their code. Although the library does look nice for some use cases
    - nicoburns 6y ago
      > Well, we can all agree that the solution should not be "we'll just require everyone to change all their code through this library" I definitely would like better language support. But IMO the solution shouldn't just be "flip a compiler switch and all your normal data structures have a stable ABI" either. What I would really like to see is a cross-language ABI (that's more fully featured than then C ABI), that can be opted into with `repr(polyabi)` or whatever it ends up being called.
- steveklabnik 6y ago
  > IMHO eventually the "editions" will be treated as minimum version to compile with. This doesn't work, because new features are not only added to newer editions, but to as many editions as possible. The vast majority of new features, when they land, are added to every edition.
zozbot234 6y ago
> Rust isn't against shared libraries per se, but it doesn't have a stable ABI. The Rust stable ABI is simply the C ABI. This doesn't work so well with features like generics as you mention, but it's good enough for interfacing with separately-built shared libraries.

by pornel 6y ago

Luker88 6y ago

> Rust isn't against shared libraries per se, but it doesn't have a stable ABI. I'd like to point out that this effectively means "it's not against shared libs, but it will actively ignore anything needed to work with them" The "move fast and break things" is fine, as long as you are the last link in the chain. Rust is the first. > ...there's only one Rust version. Every Rust edition can use any Rust feature, as long as it parses. For example, everything new added in 2020 is available in the Rust 2015 edition. IMHO this is a great feature...for the last link in the chain, not the first. Note how this is only possible since for now there is only one rust compiler. As soon as GCC or others get ready, how do we sync between features supported? IMHO eventually the "editions" will be treated as minimum version to compile with. Also, as more and more software is written in rust, lack of lts will force the users to update whole systems every 2 months (and making dynamic linking impossible will only worsen things). I still get 30Mb/s flat connections, and even with that multi-GB updates are a pain. Now imagine that for countries that are worse off. It's not impossible to work with, it just makes a lot of management things a constant (small?) pain that we had eliminated before.

nicoburns 6y ago
> I'd like to point out that this effectively means "it's not against shared libs, but it will actively ignore anything needed to work with them" There are libraries that enable this: https://docs.rs/abi_stable/0.9.3/abi_stable/ https://docs.rs/abi_stable/0.9.3/abi_stable/
- Luker88 6y ago
  Well, we can all agree that the solution should not be "we'll just require everyone to change all their code through this library" static vs dynamic is a linker (and LTO) problem, we can't start asking everyone everywhere to change all their code. Although the library does look nice for some use cases
  - nicoburns 6y ago
    > Well, we can all agree that the solution should not be "we'll just require everyone to change all their code through this library" I definitely would like better language support. But IMO the solution shouldn't just be "flip a compiler switch and all your normal data structures have a stable ABI" either. What I would really like to see is a cross-language ABI (that's more fully featured than then C ABI), that can be opted into with `repr(polyabi)` or whatever it ends up being called.
steveklabnik 6y ago
> IMHO eventually the "editions" will be treated as minimum version to compile with. This doesn't work, because new features are not only added to newer editions, but to as many editions as possible. The vast majority of new features, when they land, are added to every edition.

zozbot234 6y ago

> Rust isn't against shared libraries per se, but it doesn't have a stable ABI. The Rust stable ABI is simply the C ABI. This doesn't work so well with features like generics as you mention, but it's good enough for interfacing with separately-built shared libraries.