3 ms·

> Updating the minimum supported Rust version is a breaking change that should not be done lightly. Someone should tell that to Rust library devs, because from

> Updating the minimum supported Rust version is a breaking change that should not be done lightly. Someone should tell that to Rust library devs, because from what I understand, their packaging ecosystem pretty much always assumes that all libraries are running on the latest version of Rust. There's no "commonly used versions" or LTS builds for Rust, so it seems that every packaging maintainer just supports the latest and everyone is up shitcreek if a new version changes and hard breaks code for older Rust. With how micropackage oriented Rust is, you practically can only jump to the newest version if you want your builds to keep working since I doubt you'll be using stdlib-only Rust. Compare and contrast every (anecdotal) Rust users favorite bugbear, Python, where if you're building a library, it's pretty commonly assumed that you can follow one of the two major deprecation points for Python versions (end of bugfixes or end of security updates), which means most major libraries usually follow one of the two for the internal features (and therefore lowest version) they use.

ffsm8 2y ago
I've only done a few hello world style projects in rust, and my python experience is also almost 8 yrs ago now, so I might be wrong... But doesn't rust pull it's dependencies as bytecode vs python (which is a script language at its core) that pulls the source code? The bytecode would only ever work with the VM that it's been compiled against I think, which sounds to me like the real issue here...? I don't think you'd have this issue if you'd fetch your rust dependencies via git and then build them locally. And pre building for every version is expensive, which is likely why the rust ecosystem doesn't really do it right now. And I doubt it's gonna change unless a MAMA (Microsoft, Apple, Meta, Alphabet) company "embraces" it... The EEE style
- steveklabnik 2y ago
  Crates.io stores packages as source code. Rust does not have a VM, and doesn't use bytecode. That being said, it could in theory serve them as binary code, which yes, would then mean that it would need to be stored per version and per architecture both, which would be quite a lot more than the source that's stored now.
afdbcreid 2y ago
Work, is being done, though: https://github.com/rust-lang/cargo/issues/13873 https://github.com/rust-lang/cargo/issues/13873.

ffsm8 2y ago

I've only done a few hello world style projects in rust, and my python experience is also almost 8 yrs ago now, so I might be wrong... But doesn't rust pull it's dependencies as bytecode vs python (which is a script language at its core) that pulls the source code? The bytecode would only ever work with the VM that it's been compiled against I think, which sounds to me like the real issue here...? I don't think you'd have this issue if you'd fetch your rust dependencies via git and then build them locally. And pre building for every version is expensive, which is likely why the rust ecosystem doesn't really do it right now. And I doubt it's gonna change unless a MAMA (Microsoft, Apple, Meta, Alphabet) company "embraces" it... The EEE style

steveklabnik 2y ago
Crates.io stores packages as source code. Rust does not have a VM, and doesn't use bytecode. That being said, it could in theory serve them as binary code, which yes, would then mean that it would need to be stored per version and per architecture both, which would be quite a lot more than the source that's stored now.

afdbcreid 2y ago

Work, is being done, though: https://github.com/rust-lang/cargo/issues/13873 https://github.com/rust-lang/cargo/issues/13873.