2018 has been a year of firsts for Rust. Most importantly, it has been the first year with an edition, and with that edition, we’ve seen some major growing pains.
Editions are a necessary evil for the Rust ecosystem - breaking changes are sometimes for the best, especially while the language is still young, but editions also have major downsides. The move to uniform paths has been the biggest ergonomics improvement for Rust in the time I’ve been using it, and the edition made it possible - there’s no other way we could have landed such a systemic breaking change on stable.
However, it was also a trying time; it was clear that many of the key
contributors to rustc, especially those proficient in the areas changed by
the edition, were put under an enormous amount of pressure to get their changes
shipped by the deadline. It’s important to remember that the majority of Rust’s
contributors are doing their work on a volunteer basis - crunch is bad enough
when you’re getting paid to do the work; it’s immoral to let it permeate into
open-source work. I don’t think the edition quite met this bar, but future
roadmaps should be designed specificially to prevent this kind of situation
ever occuring in the Rust community.
So how should we plan for the next edition to handle these teething issues better? Well, I think we should start by thinking about why we would need another edition at all. I’m not saying we shouldn’t have another one, I’m saying we shouldn’t have one for the sake of it. At the moment, there’s an expectation that editions are going to be a three-year periodic thing, like how a new stable is released every 6 weeks. I argue that we should avoid an edition at all costs, unless we have a breaking change we want to make. That is the purpose of editions. Not to release new features - that’s the job of stabilisation and the 6-week release schedule. Also not to set a theme for a long period of work - that’s the job of RFCs and this yearly roadmap process.
We should keep in mind that editions really are a necessary evil and use them for what they do best: allowing us to make breaking changes without breaking the whole ecosystem. If we restrict editions to this role, the periodic release thing makes far less sense, and I like that. The next edition shouldn’t be in 2021 because that’s three years on from 2018, the next edition should be whenever we want to implement feature(s) that are not compatible with the normal stable release schedule.
rustc guide. One of my personal
goals for 2019 will be to familiarise myself more with the compiler’s internal architecture by contributing to the guide.xargo / cargo-xbuild into Cargo proper, so we can build our own sysroot cratesasm (but not stabilisation, in my opinion, until they’ve seen more use)