# 2019 Roadmap

- Feature Name: N/A
- Start Date: 2019-03-07
- RFC PR: [rust-lang/rfcs#2657](https://github.com/rust-lang/rfcs/pull/2657)
- Rust Issue: N/A

## Summary
[summary]: #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.

[RFC 1728]: https://github.com/rust-lang/rfcs/blob/26197104b7bb9a5a35db243d639aee6e46d35d75/text/1728-north-star.md

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!

[2018 survey]: https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html
[call for blog posts]: https://readrust.net/rust-2019/

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
[Detailed description]: #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][r@w]. 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][challenges].

[challenges]: https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html#challenges
[r@w]: https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html#rust-at-work
[growing larger]: https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html#how-much-do-you-use-rust
[2018 Rust Survey]: https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html

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"](https://www.jonathanturner.org/2018/12/the-fallow-year.html)

> 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"](https://blog.hwc.io/posts/rust-2019/)

> 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"](https://raphlinus.github.io/rust/2018/12/16/rust-2019.html)

> 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"](https://blog.ryanlevick.com/posts/rust-2019/)

> 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"](https://boats.gitlab.io/blog/post/rust-2019/)

We don't have space to quote every single post; if you'd like to read them
all, you can over at [Read Rust](https://readrust.net/rust-2019/). 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
[By team]: #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](https://gist.github.com/nrc/6f0fb3b66d3b043aace30217128f3af9) identifies a few major themes:

- **Better support for cross compilation:**
    - Try to incorporate some of the innovations from tools like [Xargo](https://github.com/japaric/xargo), [cross](https://github.com/rust-embedded/cross), [Rustup](https://github.com/rust-lang/rustup.rs), and [WASM-Pack](https://github.com/rustwasm/wasm-pack) into cargo itself.
- **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:**
    - Work on [custom registries](https://github.com/rust-lang/cargo/issues/6589),
[offline mode](https://github.com/rust-lang/cargo/issues/4686), and 
[improving profiles](https://github.com/rust-lang/rust/issues/48683) is nearly done, and we intend to see those items over the finish line.

### 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](https://github.com/rust-lang/compiler-team).

One project worth calling out in more detail is the [**RLS 2.0
effort**](https://github.com/rust-lang/compiler-team/tree/master/working-groups/rls-2.0).
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.

[Chalk]: https://github.com/rust-lang-nursery/chalk
[Polonius]: http://github.com/rust-lang-nursery/polonius
[rust-analyzer project]: https://github.com/rust-analyzer/rust-analyzer

### 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](https://github.com/rust-dev-tools/dev-tools-team/blob/master/roadmaps/ides-and-editors-2019.md), and the rustdoc team [here](https://github.com/rust-dev-tools/dev-tools-team/blob/master/roadmaps/rustdoc-2019.md).

### 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:**
    - [Introduce working groups](http://smallcultfollowing.com/babysteps/blog/2019/02/22/rust-lang-team-working-groups/) with the goal of increasing transparency and lowering the barrier to get involved 
    - Create a [lang-team repository](https://github.com/rust-lang/lang-team/) to help track what is happening and how to get involved
- **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.

[2018 Roadmap RFC]: https://rust-lang.github.io/rfcs/2314-roadmap-2018.html

### 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](https://blog.yoshuawuyts.com/async-ecosystem-wg/):

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

[Tide web framework]: https://docs.rs/tide/0.0.5/tide/

### CLI apps

The CLI working group's [2019
roadmap](https://paper.dropbox.com/doc/0lRnShqsfMlfS6ylXrX9h) focuses on
three main themes:

- the **design and maintenance of clap v3.0**
- working on the **testing crates**, such as [`assert_cli`](https://crates.io/crates/assert_cli), [`assert_fs`](https://crates.io/crates/assert_fs), and [`assert_cmd`](https://crates.io/crates/assert_cmd)
- improving the **organizational structure** of the WG through meetings, organization, and branding

### WebAssembly

The [2019 WebAssembly WG roadmap](https://github.com/rustwasm/rfcs/pull/7)
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](https://paper.dropbox.com/doc/ZmUYvRp4PjX1jqq6LSxcZ) 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](https://github.com/rust-secure-code/wg) is a
newer working group focused on making it easy to write secure code in Rust.
The [2019
roadmap](https://medium.com/@shnatsel/security-as-rust-2019-goal-6a060116ba39)
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
