core (roadmap)
This RFC proposes the 2019 Rust Roadmap, in accordance with RFC 1728. The goal of the roadmap is to lay out a vision for where the Rust project should be in a year's time.
The proposal is based on the 2018 survey, our annual call for blog posts, direct conversations with individual Rust users, and discussions at the 2019 Rust All Hands. Thanks to everyone who helped with this effort!
In short, 2019 will be a year of rejuvenation and maturation for the Rust project. Much of the focus is on strengthening our foundations and paying down debt, both technical and organizational.
In 2018, the Rust team came together around a shared vision: Rust 2018, our first real edition. We not only decided to develop Rust 2018, but also the idea of editions themselves, all in one year. 2018 was also a fantastic year for production usage of Rust. Some of the largest names in tech have started relying on Rust as a key part of their stack. Smaller companies have started to build great things with our technology as well.
Looking at the 2018 Rust Survey results, one can start to see a shift as well. Rust projects are growing larger, with more and more people using Rust at work. Ergonomics no longer ranks as the number one concern amongst respondents: instead, we see a need for mature libraries, a better IDE experience, and more Rust adoption.
Shipping the 2018 edition was both a herculean task and a great success. But it also created a lot of debt, both technical and organizational. When reading the Rust 2019 blog posts, and when having conversations with team members at the Rust All Hands, a general theme developed: 2019 should still be a year of shipping, but a certain kind of shipping. Words like confidence, maturity, practicality, productivity, sustainability, and stability were often used. This should be a year of reflection, one of polish, one of finishing plans that were started long ago.
In some ways, it's easier to describe what this year should not be, rather than what it should be. This should not be a year of dreaming up large new features, one of drastic change, or one that makes your old code feel obsolete.
Here's some select quotations from a few Rust 2019 posts that really resonated with folks:
Let’s finish what we started. As much as is possible and practical this year, let’s set aside new designs and ship what we’ve already designed. Let’s tackle challenges we haven’t had time to give our full attention.
- Jonathan Turner, "The fallow year"
I believe not only that the processes and institutions of Rust need to be shored up, but that special attention should be paid to people. Ultimately, people are what drives the language forward, whether it be through design, implementation, or outreach. If no people want to work on Rust, or are blocked from working on Rust, the language will stagnate. ...
This is not to say that there should not be any movement on improving features or process. Just that their effects and costs should be measured in people, as well as in technology.
- hwc, "Rust 2019: Go Slow"
In this post, I’ll refer to a highly simplified maturity life cycle with three stages: research, development, and polish. Different parts of the Rust ecosystem are at different levels of maturity. It’s important for effort to match the actual stage in the life cycle, ideally to push it to the next. For example, I consider the language to mostly be in the “polish” stage. Continuing to treat it as research would bring dependent types, virtual structs, etc., which would be interesting but disruptive. Conversely, we don’t know exactly what we want for GUI, so trying to drive that to a standardized solution too early will likely get us to a suboptimal place.
Many mature products have alternating releases focused on new features, then stabilization... 2018 has seen a lot of new features, so I think it’s time for a stabilization phase.
- Raph Levien, "My thoughts on Rust 2019"
If you’re familiar with the history of Rust you might be confused with a call to stabilization. After all, Rust 2015 (a.k.a 1.0) was all about stabilization and the team has actually done a pretty good job with achieving this goal. So what gives?
While Rust 2015 defined stabilization around language backward compatibility, it’s time for the language, the tooling, the ecosystem and the governance to stabilize. Each of these characterize stability in a different way.
- Ryan Levick, "Rust 2019: Stabilization"
The Rust project has been growing like a startup for the last several years. This has some good aspect - “hockeystick curves” - but it has some very bad aspects as well. If this project is going to have a chance of sustaining itself in the long term, we need to get real about dealing with the organizational debt we have accumulated. I think we have serious problems at every level of our organization that need to be addressed, and I’m going to enumerate them from my personal perspective.
- withoutboats, "Organizational Debt"
We don't have space to quote every single post; if you'd like to read them all, you can over at Read Rust. And of course, these themes are not universally shared among Rust developers, but there is a common theme in many of them: slow down, pay off debt, finish what we've started.
With this general theme in mind, here are the high-level plans from each of the teams for the upcoming year, in alphabetical order. These summaries are based on discussions had at the All Hands; each team may also post a more detailed individual roadmap. The summaries are meant to show plans in broad strokes and how they fit together for the project.
The cargo team 2019 roadmap identifies a few major themes:
The community team has decided to make "solidifying" the theme of the year. While it has a lot of ideas of what could be done, a lot of existing projects are useful and would be more so with more time and investment. Projects like RustBridge, event support, the YouTube channel and modernizing the community calendar will take priority.
Internationalization will also be a big subject over the next year. This both means making Rust more accessible to non-English speakers and growing our global reach. This will bring with it organizational changes to allow the team to grow out of its current locations. It's hard to contribute to the community team if you are in timezones incompatible with meetings in US/EU timezones and the community team wants to change that.
Previously a mainly outwards-focused team, the team also plans to assist other teams more in communicating better with the wider community and be more helpful to the project internally. For that, new reporting structures are planned.
The compiler team has five main themes of work for this year:
async fn support, or improvements to the trait system Some of the specific projects we have in mind are as follows:
One project worth calling out in more detail is the RLS 2.0 effort. The existing RLS, while functional, was never deeply integrated into rustc itself. Over the past two years, we have rewritten the back end of rustc to use an incremental and demand-driven infrastructure. To get the IDE experience we truly want, we need to see that work through for the front end of the compiler as well. However, this part of rustc is one of its oldest, and there are significant design questions involved in how best to do that.
This is where the RLS 2.0 effort comes in. The plan is to build a prototype of the new front-end, thus enabling a truly first-class IDE experience. Wherever possible, we aim to share code between this front-end and rustc by extracting libraries, such as Chalk (for traits), Polonius (for the borrow checker), and a new library focusing on name resolution. Eventually, we will merge this new front-end with the remaining bits of back-end from rustc.
One of the newer teams, the Crates.io Team is going to be focused on growing itself, paying down technical debt in the codebase, and establishing themes for long-term priorities.
The Dev Tools team has a few core functions:
They'll be working to fulfill these functions this year, along with looking for ways to improve their internal processes.
Individual devtools subteams may be coming up with their own roadmaps, you can see the one of Cargo above, the IDE team here, and the rustdoc team here.
The documentation team is going to be completely reformulating itself, and possibly re-naming itself as the "learning team." They're working on an RFC to do so, and that will lay out the roadmap. Stay tuned!
The language team has four areas of interest this year:
The library team will be focusing on maintaining the standard library. The team will handle specialized tasks such as overseeing and reviewing ports of the standard library to new platforms, as well as typical bug fixes and performance improvements.
The team doesn't currently have the bandwidth to take on a large number of
new features for the standard library, but is specifically planning to
develop a plan of attack for custom allocators associated with instances of
collections (e.g. Vec<T, A: Alloc>).
In addition to the Rust teams, we also have a number of active working groups that report to the core team. These groups are tasked with exploring a particular domain and making recommendations to other Rust teams with decision-making power. This section contains the 2019 priorities for each of these working groups.
The 2018 roadmap comissioned a "Networking Services" domain working group. Since then, that working group has split into two parts:
Future trait and async-await syntax.The CLI working group's 2019 roadmap focuses on three main themes:
assert_cli, assert_fs, and assert_cmdThe 2019 WebAssembly WG roadmap adopts the overall theme of practicality. The intent is to focus on these areas:
wasm-pack.The Embedded WG's 2019 Roadmap designates productivity as their theme for 2019. They plan to focus on three main points:
The Secure code working group is a newer working group focused on making it easy to write secure code in Rust. The 2019 roadmap for the Secure Code working group focuses on four areas of improvement: