A response to the call for 2019 roadmap blog posts.
In case you missed it, we released our second edition of Rust this year! An edition is an opportunity to make backwards incompatible changes, but more than that it's an opportunity to bring attention to how programming in Rust has changed. With the 2018 edition out of the door, now is the time to think about the next edition: how do we want programming in Rust in 2022 to be different to programming in Rust today? Once we've worked that out, lets work backwards to what should be done in 2019.
Without thinking about the details, lets think about the timescale and cadence it gives us. It was three years from Rust 1.0 to Rust 2018 and I expect it will be three years until the next edition. Although I think the edition process went quite well, I think that if we'd planned in advance then it could have gone better. In particular, it felt like there were a lot of late changes which could have happened earlier so that we could get more experience with them. In order to avoid that I propose that we aim to avoid breaking changes and large new features landing after the end of 2020. That gives 2021 for finishing, polishing, and marketing with a release late that year. Working backwards, 2020 should be an 'impl year' - focussing on designing and implementing the things we know we want in place for the 2021 edition. 2019 should be a year to invest while we don't have any release pressure.
To me, investing means paying down technical debt, looking at our processes, infrastructure, tooling, governance, and overheads to see where we can be more efficient in the long run, and working on 'quality of life' improvements for users, the kind that don't make headlines but will make using Rust a better experience. It's also the time to investigate some high-risk, high-reward ideas that will need years of iteration to be user-ready; 2019 should be an exciting year!
The 2021 edition
I think Rust 2021 should be about Rust's maturity. But what does that mean? To me it means that for a programmer in 2022, Rust is a safe choice with many benefits, not a high-risk/high-reward choice. Choosing Rust for a project should be a competitive advantage (which I think it is today), but it should not require investment in libraries, training, or research.
Some areas that I think are important for the 2021 edition:
- sustainability: Rust has benefited from being a new and exciting language. As we get more mature, we'll become less exciting. We need to ensure that the Rust project has sufficient resources for the long term, and that we have a community and governance structure that can support Rust through the (hopefully) long, boring years of its existence. We'll need to think of new ways to attract and retain users (as well as just being awesome).
- diversity: Rust's community as a good reputation as a welcoming community. However, we are far from being a diverse one. We need to do more.
- mature tools: Cargo must be more flexible, IDE support must be better, debugging, profiling, and testing need to be easy to use, powerful, and flexible. We need to provide the breadth and depth of tool support which users expect from established languages.
- async programming: high-performance network programming is an amazing fit for Rust. Work on Linkerd and Fuchsia has already proved this out. Having a good story around async programming will make things even better. I believe Rust could be the best choice in this domain by a wide margin. However, building out the whole async programming story is a huge task, touching on language features, libraries, documentation, programming techniques, and crates. The current work already feels huge and I believe that this is only the beginning of iteration.
- std, again: Rust's standard library is great, a point in favour of Rust. Since Rust 1.0 there have been steady improvements, but the focus has been on the wider ecosystem. I think for the next edition we will need to consider a second wave of work. There are some fundamental things that are worth re-visiting (e.g., Parking Lot mutexes), and a fair few things where our approach has been to let things develop as crates 'for now', and where we either need to move them into std, or re-think user workflow around discoverability, etc. (e.g., Crossbeam, Serde).
- error handling: we really need to improve the ergonomics of error handling. Although the mechanism is (IMO) really great, it is pretty high-friction compared to exceptions. We should look at ways to improve this (
throwsin function signatures, etc.). I think this is an edition issue since it will probably require a breaking change, and at the least will change the style of programming.
- macros: we need to 'finish' macros, both procedural and declarative. That means being confident about our hygiene and naming implementation, iterating on libraries, stabilising everything, and supporting the modern
- internationalisation: we need to do much better. We need internationalisation and localisation libraries on a path to stabilisation, either in std or discoverable and easily usable as crates. It should be as easy to print or use a multi-locale string as a single-locale one. We also need to do better at the project-level - more local conferences, localised documentation, better ways for non-English speakers to be part of the Rust community.
Let's keep focussing on areas where Rust has proven to be a good fit (systems, networking, embedded (both devices and as performance-critical components in larger systems), WASM, games) and looking for new areas to expand into.
So, with the above in mind, what should we be doing next year? Each team should be thinking about what are the high-risk experiments to try. How can we tackle technical (and community) debt? What can be polished? Lets spend the year making sure we are on the right track for the next edition and the long-term by encouraging people to dedicate more energy to strategy.
Of course we want to plan some concrete work too, so in no particular order here are some specific ideas I think are worth looking into:
- discoverability of libraries and tools: how does a new user find out about Serde or Clippy?
- project infrastructure: are bors, homu, our repo structures, and our processes optimal? How can we make contributing to Rust easier and faster?
- the RFC process: RFCs are good, but the process has some weaknesses: discussion is scattered around different venues, discussions are often stressful, writing an RFC is difficult, and so forth. We can do better!
- project governance: we have to keep scaling and iterating. 2019 is a good opportunity to think about our governance structures.
- moderation and 'tone' of discussion: we need to keep scaling moderation and think about better ways to moderate forums. Right now we do a good job of enforcing the CoC and removing egregious offenders, however, many of our forums can feel overwhelming or hostile. We should strive for more professional and considerate spaces.
- security of Rust code: starting the secure code working group is very timely. I think we're going to have look closely at ways we can make using and working with Rust code safer. From changes to Cargo and crates.io, to reasoning about unsafe code.
- games and graphics: as well as keeping going with the existing domain working groups, we should also look at games and graphics. Since these are such performance sensitive areas, Rust should be a good fit. There is already a small, but energetic community here and some initial uses in production.
- async/await and async programming: we need to keep pushing here on all fronts (language, std, crates, docs, gaining experience)
And lets dive a tiny bit deeper into a few areas:
- Cargo: Cargo needs to integrate better into other build system and IDEs. There are a lot of places people want more flexibility, it will take another blog post to get into this.
- More effort on making the RLS good.
- Better IDE experience: more features, more polish, debugging and profiling integration.
- integrating Rustdoc, docs.rs, and cargo-src to make a best-in-class documentation and source code exploration experience
- work on a query API for the compiler to be a better base for building tools. Should support Clippy as well as the RLS, code completion, online queries, etc.
Even more than the other areas, the language team needs to think about development cadence in preparation for the next edition. We need to ensure that everything, especially breaking changes, get enough development and iteration time.
Some things I think we should consider in 2019:
- generic associated types or HKTs or whatever: we need to make sure we have a feature which solves the problems we need to solve and isn't going to require more features down the road (i.e., we should aim for this being the last addition to the trait system).
- specialisation: is this going to work? I think that in combination with macros, there are some smart ways that we can work with error types and do some inheritance-like things.
- keep pushing on unfinished business (macros, impl Trait, const functions, etc.).
- named and optional arguments: this idea has been around for a while, but has been low priority. I think it would be very useful (there are some really ergonomic patterns in Swift that we might do well to emulate).
- enum variant types: this is small, but I REALLY WANT IT!
- gain experience with, and polish the new module system
- identify and fix paper cuts
Nothing really new here, but we need to keep pushing on compiler performance - it comes up again and again as a Rust negative. We should also take the timing opportunity to do some refactoring, for example, landing Chalk and doing something similar for name resolution.