Rust has many fantastic things going for it, and has contributed a huge amount to the programming world, even at this early stage. The focus on safety and the ownership model will pave the road to a future of safer, more reliable software, whether through the language itself or its impacts on how programmers think about memory safety. On top of these technological achievements, Rust has a great community on the whole, and is a forerunner in the future of compassionate software development.

Post-edition reflection

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.

Other things I’m looking forward to

• More progress on the 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.
• Chalk integration and all the cool things that’ll bring us!
• Easier bare-metal development, since my main project at the moment is the Pebble microkernel. Rust is the perfect language for kernel development, but it’s still a bit of a pain to get Rust compiling for these sorts of targets. Most of this will come with time (the progress on the embedded scene has been amazing), but particularly I’d like to see work on:
  • Stabilising and documenting custom target specifications
  • Moving the capabilities of xargo / cargo-xbuild into Cargo proper, so we can build our own sysroot crates
  • Improvements in inline asm (but not stabilisation, in my opinion, until they’ve seen more use)
  • Maybe the formation of a working group for kernel development