2019 Roadmap

Summary

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.

Detailed description

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.

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.

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.

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.

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.

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.

By team

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.

Cargo

The cargo team 2019 roadmap identifies a few major themes:

  • Better support for cross compilation:
  • Focus on the cargo ecosystem by supporting plugins (custom commands):
    • Custom commands enable faster experimentation, bringing new and flexible workflows to users sooner rather than later.
    • Make plugins more discoverable.
    • Provide library crates for parts of cargo to make it easier to create plugins.
  • Compile times:
    • Investigate ways that cargo can help to reduce compilation time, including potentially distributing binaries for builds from crates.io.
  • Addressing technical debt:
    • There are a number of parts of cargo that could use refactoring, and we plan to spend some time on that.
  • Finishing “almost complete” work:

Community

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.

Compiler

The compiler team has five main themes of work for this year:

  • Improving “core strength” by lowering raw compilation times and also generating better code (which in turn can help with compilation times)
  • Improved IDE integration, including support for typed completions
  • Extracting parts of rustc into libraries, which are easier to understand and maintain but also help in developing a Rust specification
  • Supporting lang team in key feature development, such as around async fn support, or improvements to the trait system
  • Improving our documentation and organization, helping to make it clearer what is going on at any given time, and how people can get involved.

Some of the specific projects we have in mind are as follows:

  • Parallelizing rustc, which should help with improving raw compilation times and also increasing IDE responsiveness.
  • Introducing MIR optimizations, which will improve the quality of our generated code, but also may help reduce compilation time by giving LLVM less work to do (LLVM remains a large percentage of overall compilation time).
  • Introducing working groups for each project, and track them on the compiler-team repository.

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.

Crates.io

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.

Dev Tools

The Dev Tools team has a few core functions:

  • liaising with the wider project
  • being a bit of a “commons” space for cross-cutting tools concerns
  • finding out what needs are yet to be addressed by tooling and filling them
  • providing some kind of quorum helping smaller tool subteams make decisions

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.

Documentation

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!

Language

The language team has four areas of interest this year:

  • Organizational:
  • Key ergonomic improvements:
    • Async/await in particular is needed to help “unlock” Async I/O
  • Finish long-standing features:
    • Rust has a number of in-progress features – such as const generics, Generic Associated Types, and specialization – that have been in development for some time. It’s time to finish their designs and ship them.
  • Reference material and guidelines:
    • Work with the documentation team on the Rust reference.
    • Produce “unsafe code guidelines” that describe what unsafe code can and cannot do.

Library

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>).

Working Groups

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.

Async Foundations and Async Ecosystem

The 2018 roadmap commissioned a “Networking Services” domain working group. Since then, that working group has split into two parts:

  • The “Async Foundations” effort, which is being led by the language design team, will focus on building the ‘core building blocks’ that belong to the language itself, such as the Future trait and async-await syntax.
  • The “Async Ecosystem” working group, meanwhile, will focus on nurturing the budding ecosystem built on top of those layers. The plan for 2019 is to focus on the Tide web framework, and help expand the ecosystem around async/await.

CLI apps

The CLI working group’s 2019 roadmap focuses on three main themes:

  • the design and maintenance of clap v3.0
  • working on the testing crates, such as assert_cli, assert_fs, and assert_cmd
  • improving the organizational structure of the WG through meetings, organization, and branding

WebAssembly

The 2019 WebAssembly WG roadmap adopts the overall theme of practicality. The intent is to focus on these areas:

  • Grow our library ecosystem by collaborating on a modular toolkit.
  • Bring multithreading to Rust-generated Wasm.
  • Integrate best-in-class debugging support into our toolchain.
  • Polish our toolchain and developer workflow, culminating in a 1.0 version of wasm-pack.
  • Invest in monitoring, testing, and profiling infrastructure to keep our tools and libraries snappy, stable and production-ready.

Embedded “bare metal” devices

The Embedded WG’s 2019 Roadmap designates productivity as their theme for 2019. They plan to focus on three main points:

  • Documentation, specially intermediate level docs covering API design patterns and coding guidelines
  • Maturing the ecosystem: growing existing libraries and highlighting projects to serve as examples
  • Filling the gaps: getting toolchain bugs fixed and polishing existing tools

Secure code

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:

  • Distribution of security patches
  • Improving code authentication
  • Reducing the need for unsafe code
  • Better verification of the standard library