Is 2018 edition a marker that there will be yearly Rust editions?
I am concerned about having deltas every six weeks for more ambitious projects.
Reading about Chucklefish and their rust experience has got me getting interested in maybe console development. But if rust is different every six weeks, that’s a pretty big turnoff as it seems sometimes the build scenarios can be rather involved, so I wouldn’t want to fiddle with it ~9 times a year.
Will there be a rust 2019 edition? I think it’d be a lovely thing to have a target like this for large corporations also. It’s easier to synchronize developers, like especially when experienced developers are teaching new devs. If that new developer is interacting with more than one teacher, he might experience multiple solutions to problems/questions. Sort of “knowledge cruft” you see, and that’s frustrating. Perl used to have this issue, and I’m sure other communities have dealt with it too.
As my post reads, I’m asking if rust is attempting to do yearly editions.
I see that it says every two or three years, so that more or less satisfies what I was trying to find out. I’m glad that there is a way for developers to interact with rust at a slower, more convenient pace.
Bear in mind, editions are not a new versioning system with a slower cadence. Versions continue to get updated within editions. Editions are a good milestone for the project and contain some kinds of changes that can’t be delivered within the normal version model.
Rust updates every six weeks but there aren’t breaking changes, so it shouldn’t be a problem in most cases.
I’d say it’s unfair to say Rust is different every six weeks. It’s maintained on a regular schedule, and it has solid mechanisms to make staying up to date easy for users.
The compiler and libraries get incremental improvements, and they’re always backwards compatible (and even new edition compilers will still support all older editions).
Rustup makes it super easy to upgrade (and downgrade) the whole toolchain on your own schedule.
Code written for Rust 1.0 still works with the latest compiler, so you don’t have to change it if you don’t want to. Once you know the language, the new additions aren’t intimidating, they’re more of “finally!” features you’ve been missing and make usage genuinely easier (e.g. recent impl Trait was a relatively big addition to the language, but it made async networking code much easier to work with).
There is a bit more churn from 3rd party libraries, but it’s entirely manageable too:
Cargo uses lock files, so once you install and compile a set of libraries, you have a guarantee you get the same set every time. It supports minimal updates of one dependency at a time (cargo update -p package), so even if you have a lock file, you can still change dependencies when you need to.
There’s a culture of using semver, having unit tests and CI.
Building of complex projects is easier with Rust. Cargo is great, and good support for Cargo workspaces helps break huge monolith into many small libraries that are individually easier to test and maintain.
This is not true, and sets expectations that will not be met. There have been (and probably will be) breaking changes, but they’re very rare and well motivated, in the “there’s no other option” sense.
No, I didn’t read the context; my fault. I just saw (what looked like) three “there are no breaking changes” (edit: as in: no breaking changes ever, anywhere) comments in a row and felt compelled to counter them.
