4 ms·

While I appreciate the fast moving pace, I have to admit that it is hurting two big things: * long term support * choice, in particular in building shared lib

While I appreciate the fast moving pace, I have to admit that it is hurting two big things: * long term support * choice, in particular in building shared libraries. While a lot can be argued on the first point, the community seems to be actively against anyone who wants to use or build stuff with shared libraries. Shared libs are extremely useful in resource constrained environments like routers, and the debate on who should update things (distro maintainers vs project maintainers) is still very well out there. But breaking compatibility every compiler release is a huge pain the butt, and will force those who need shared libs for one reason or another to work with older, unmaintained compilers, with many projects being unable to compile there (the only "edition" is 2018, 4 years now which is starting to look like C++ standard levels of time). Because like Potter's projects, who the hell ever needed an LTS release? Can't/don't want to update everything every week? Your problem. Now try to choose a single compiler release for your distro. IMHO, either you have too many big features on each release, and therefore the "editions" should track that, or those are not that big of a deal, so no edition bump is needed and we can focus on binary compatibility, maybe? maybe have sub-editions, like 2018.3? So yeah, I love rust, and this is really the only bad thing I have to say about the project. Honestly, if there was an LTS release, maybe just one for rust "edition", maybe use editions better, I think everyone would be super happy and most problems would be resolved.

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.
deleted 6y ago
[deleted]

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.

deleted 6y ago

[deleted]