For anyone like me who hasn’t seen an edition change before, it’s just a mechanism for bundling breaking changes together and making them opt-in.
We are excited to announce that the Rust 2024 Edition is now stable! Editions are a mechanism for opt-in changes that may otherwise pose a backwards compatibility risk.
aljazmerzen@fosstodon.org
on 21 Feb 13:29
nextcollapse
@Rogue@snaggen Yeah, it's a setting in Cargo.toml that you have to update manually if you want to upgrade. It is set to latest edition in new projects. And the nice thing:
it's configurable per-crate, not per-compilation. So you can depend on crates that use different editions than your crate. Which avoids ecosystem fragmentation.
it’s configurable per-crate, not per-compilation. So you can depend on crates that use different editions than your crate. Which avoids ecosystem fragmentation.
Thanks! That pre-empted my next question of how quickly crates typically update to newer editions. I guess it doesn’t matter
There is also cargo fix --edition which can update your code in a very conservative way automatically. The result might not be as idiomatic but errs on the side of having semantics that do not change.
You can think of the Rust Editions as updates to the language, that would break compatibility with previous versions. But the key here is, that you can mix crates with older versions and the new one in one project and cargo will figure out which one to use for each crate (based on the cargo.toml file). That means breaking changes without breaking compatibility of existing libraries and crates, unlike in other languages.
calcopiritus@lemmy.world
on 22 Feb 08:10
nextcollapse
The const hash map is huge. It was always a pain the have const/static hash maps. Specially since most use cases don’t need a DoS-resistant hash map. Will be migrating to 2024 as soon as possible.
sugar_in_your_tea@sh.itjust.works
on 22 Feb 18:07
collapse
Adds Future and IntoFuture to the prelude.
Woo!
std::env::set_var, std::env::remove_var… are now unsafe functions.
That’s unfortunate. I understand why it’s unsafe, but it would be cool if they were atomic or something instead. I don’t really want to clutter code with unsafe for things that are technically safe in context (e.g. unit tests for config parsing).
async closures
Baller.
Other cool stuff as usual, so I’ll be updating soon. Congrats on the release!
Edit: Looks like they messed with default lifetimes on impl Trait, but the fix was easy enough. The upgrade was otherwise smooth. Good work!
BatmanAoD@programming.dev
on 25 Feb 05:00
collapse
They did consider making environment-manipulation functions atomic; the problem is that there’s simply no way to guarantee that everything that can manipulate your process’s environment is actually beholden to whatever atomic interface Rust provides. I could be misremembering, but I think there was even some discussion with glibc maintainers about whether this could be made safe, and the answer was basically “haha no.”
threaded - newest
For anyone like me who hasn’t seen an edition change before, it’s just a mechanism for bundling breaking changes together and making them opt-in.
@Rogue @snaggen Yeah, it's a setting in Cargo.toml that you have to update manually if you want to upgrade. It is set to latest edition in new projects. And the nice thing:
it's configurable per-crate, not per-compilation. So you can depend on crates that use different editions than your crate. Which avoids ecosystem fragmentation.
Thanks! That pre-empted my next question of how quickly crates typically update to newer editions. I guess it doesn’t matter
There is also
cargo fix --editionwhich can update your code in a very conservative way automatically. The result might not be as idiomatic but errs on the side of having semantics that do not change.You can think of the Rust Editions as updates to the language, that would break compatibility with previous versions. But the key here is, that you can mix crates with older versions and the new one in one project and cargo will figure out which one to use for each crate (based on the cargo.toml file). That means breaking changes without breaking compatibility of existing libraries and crates, unlike in other languages.
The const hash map is huge. It was always a pain the have const/static hash maps. Specially since most use cases don’t need a DoS-resistant hash map. Will be migrating to 2024 as soon as possible.
Woo!
That’s unfortunate. I understand why it’s unsafe, but it would be cool if they were atomic or something instead. I don’t really want to clutter code with unsafe for things that are technically safe in context (e.g. unit tests for config parsing).
Baller.
Other cool stuff as usual, so I’ll be updating soon. Congrats on the release!
Edit: Looks like they messed with default lifetimes on impl Trait, but the fix was easy enough. The upgrade was otherwise smooth. Good work!
They did consider making environment-manipulation functions atomic; the problem is that there’s simply no way to guarantee that everything that can manipulate your process’s environment is actually beholden to whatever atomic interface Rust provides. I could be misremembering, but I think there was even some discussion with glibc maintainers about whether this could be made safe, and the answer was basically “haha no.”