Disclaimer: I am not in the Rust team, so I may make wrong assumptions.
I did not planned to do a 2020 post, since my wish list for 2020 was not especially creative:
- Finish the 2019 roadmap
- A cross-platform, native like, GUI library.
However, when I read the Nick Cameron's 2020 blog post, I thought about something that might be interesting about editions. One of the Nick's points was that a 2021 edition would be useful as a rallying point to highlight progress on “async”. I agree that a rallying point is desirable, but I believe the edition system is a terrible way to do that.
The problem with editions as rallying point :
The edition system was introduced with two orthogonal goals:
- introduce features that break the compatibility at the source level, without breaking the ecosystem.
- serve as milestone to advertise the overall Rust progress.
While the first goal is a huge success, the second goal seems a failure to me. What most people remember about the 2018 edition are the module system, the dyn keyword and a rushed website that most of the community considers as a regression. The edition system failed to bring to light most of the great improvements that happened in Rust since 2015.
The problem is that, when an edition come out, the whole set of changes since the release of the last edition has no concrete meaning, since nobody should be using this unsupported version anymore. The focus naturally goes to the breaking changes.
Another problem is the fixed schedule that does not match the usual Rust rolling release model where new features are not rushed and stay in nightly until they are ready and community approved. The new web site, revealed too late to consider feedback, was the most obvious example for the community , and according to some blog posts from the Rust teams, releasing the breaking changes on time caused stress on them too.
I think the edition system is great for language evolution, but it should be breaking changes focused and not time constrained. There is no reason to consider an edition if there is no breaking changes in the pipeline.
So how to advertise Rust progress ?
If we want to mark progress, we need something to introduce actual changes on a large period, and there is an often-requested feature that meet this need: LTS versions. However, LTS are usually released on a fixed schedule that may not be optimal to highlight the overall Rust progress. So I suggest a mechanism between the big releases and LTS, let's call it Milestone versions.
When we believe a particular Rust version is great to show off the Rust progress, we ship it as a Milestone version. Milestone versions would have a code name that help to advertise them, like Firefox Quantum helped advertise Firefox speed improvement. These versions would be supported at least 2 years or 3 month after the release of the next Milestone, whichever come last (numbers for illustrative purposes only). So there would be an actual changelog to display between two Milestones.
For instance (completely hypothetical timeline) :
- Most of the async shortcoming are fixed in the version 1.44. We can release it as a Milestone version with a cool name like "Async is in the place, Milestone 1".
- One years and a half later, Rust is able to use const everywhere you ever dream to, we could release another version as milestone: "Everything’s const, Milestone 2". Milestone 1 and Milestone 2, should be supported six month in parallel.
- Three year later, Rust now support quantum computers, we release a "Rust Quantum, Milestone 3". The Milestone 2 support had to be extended for one year + 3 month.
With Milestones, you can advertise actual improvements between Milestone versions as well as introducing LTS, an expected feature for Rust adoption in production.
Long support drawbacks
While long period support is a feature often requested to be able to use Rust in production, it will require additional work. I have no idea of the actual weight of this additional charge.
Another risk would be that the user base would be split between Milestone users and stable users. But I believe the community is now large enough. I don't fear that stable users count would drop that much.
If the drawbacks of long term support are too strong, we may just keep the idea of Milestones with code names to advertise particular stable versions with no additional support.