# Rust 2020 Roadmap

- Feature Name: N/A
- Start Date: 2020-01-22
- RFC PR: [rust-lang/rfcs#2857](https://github.com/rust-lang/rfcs/pull/2857)
- Rust Issue: N/A

## Summary
[summary]: #summary

Lays out the Rust roadmap for 2020 in pursuit of our mission
to empower everyone to build reliable and efficient software.
The roadmap takes the form of the following goals for the project:

* Prepare for a possible Rust 2021 Edition
* Follow-through on in-progress designs and efforts
* Improve project functioning and governance:
  * Improve visibility into the state of initiatives and design efforts
  * Increase mentoring, leadership, and organizational bandwidth
  * Make design discussions more productive and less exhausting

## Motivation
[motivation]: #motivation

Every year, the Rust project plans out a roadmap, in accordance with
[RFC 1728]. The goal of the roadmap is to

* Align the Rust project on our priorities in the coming year, to help
  teams focus their efforts on addressing the most prominent problems
* Communicate these priorities to the community and outside world

To that end, the roadmap describes the general goals that we believe the
teams ought to be pursuing. These goals were chosen based on a number of
sources:

[RFC 1728]: https://rust-lang.github.io/rfcs/1728-north-star.html

* Preliminary analysis of the [2019 survey], which took place in
  December.
* The [many #rust2020 blog posts][rust2020] written in response to our
  [call for blog posts].
* The thoughts and inputs from the members of the various Rust teams.

[2019 survey]: https://blog.rust-lang.org/2019/12/03/survey-launch.html
[rust2020]: https://readrust.net/rust-2020/
[call for blog posts]: https://blog.rust-lang.org/2019/10/29/A-call-for-blogs-2020.html

The roadmap is not meant to be "exclusive" -- that is, it's not the
case that every single thing we do must tie in some way to the
roadmap. But we do expect that our largest efforts will be put towards
addressing the roadmap goals.

### Structure of the roadmap

The roadmap this year is based around a few central themes. These goals
are intentionally rather broad -- they are meant to be interpreted
throughout the year by the various teams, as they make decisions about
what to pursue.

The roadmap does not contain specific technical details or
proposals. We encourage the individual teams to post their thoughts
about goals and ongoing projects for 2020, either in the form of
[Inside Rust] blog posts or as [internals] threads.

[Inside Rust]: https://blog.rust-lang.org/inside-rust/index.html
[internals]: https://internals.rust-lang.org/

## The goals

We have laid out three 'major goals' for Rust in 2020:

* Prepare for a possible Rust 2021 Edition
* Follow-through on in-progress designs and efforts
* Improve project functioning and governance:
  * Improve visibility into the state of initiatives and design efforts
  * Increase mentoring, leadership, and organizational bandwidth
  * Make design discussions more productive and less exhausting

### Prepare for a Rust 2021 edition

[Editions] were established as a means to help communicate the progress of
the Rust language and provide a rallying point for overarching pieces of work.
One of our goals for this year should be plan out any changes that we
wish to make as part of the next Rust edition. If we are to continue
the three-year cadence established with the release of Rust 2018, then
the next edition would be released in 2021.

[Editions]: https://rust-lang.github.io/rfcs/2052-epochs.html

One thing that we learned quite clearly from the experience of Rust
2018 was the importance of preparation. If we wish to do a Rust 2021
edition, we need to be planning for it now. **The goal should be that
any changes we wish to make in Rust 2021 are completed by October of
2020**. Completed here means that the changes are available on
Nightly. This leaves 2021 to do tooling and polish work, such as lints
that will port code forward.

We have not yet formally decided to do an edition. **One specific scenario
where we *would* expect to go forward with an edition is if we have work
landed by October 2020 that relies on one.** The final decision will
be made in October with an RFC, and it will be based on the work that
has been completed until that date.

**What might an edition contain?** We've got a number of "in progress"
language design features that may require minor changes tied to an
edition, but this list is by no means exhaustive:

* Error handling, which could potentially see the introduction of new syntactic
  forms;
* Improvements to the trait system;
* Improvements to unsafe code, which might involve introducing new syntax like
  the `&raw` form proposed in [RFC 2582].

[RFC 2582]: https://rust-lang.github.io/rfcs/2582-raw-reference-mir-operator.html
[#57893]: https://github.com/rust-lang/rust/issues/57893

One goal for this year, then, is to flesh out those areas in more detail and
decide what changes, if any, we would like to do for Rust 2021. It is key to
identify and plan out the changes we want to make sufficiently early that the
tooling and documentation around these changes has time to mature before
shipping.

**Editions and our stability promises.** Note that, as ever, issuing a
new edition does not mean that old code stops compiling. Furthermore,
any edition-related change would require appropriate tooling to help
people transition their code, though the tooling might not be
completed this year.

It is notable also that the 2018 edition packaged two "experiences" into one:
breaking changes and a reflection for the world on the work in the past 3 years.
That did not go as perfectly as we had hoped, and to this day there remains some
confusion on this point. We should, by 2021, identify the marketing strategy we
will use for the edition, but this should not affect the choices of breaking
changes (as those will always be tied to the edition mechanism). We may,
however, choose to decouple the edition from the progress report mechanism. This
RFC explicitly does not identify which of these is the better approach to take.

### Follow-through with in-progress designs and efforts

> I work with Rust for several years. The language is great, the
> tooling is superb, but I have one growing uneasy feeling too. There
> are several features that are almost ready, but not there yet. They
> are in this state for a long time.
>
> -- [vorner](https://vorner.github.io/2019/11/12/rust-2020.html)

A major theme highlighted in numerous blog posts and team member's
feedback is the tendency for Rust efforts to sometimes "get stuck"
without being fully completed. Over the years, Rust has accumulated a
number of "almost complete" efforts -- these range from
language/library features to compiler refactorings to community
projects.

One of our goals for this year is to reduce this backlog of "in
progress" ideas, whether by implementing them or by explicitly opting
to reject or postpone the idea. This does not mean that we should not
accept any new work, but we should have a high level goal in mind of
finishing the year with less, rather than more, "planned" work.

There are several motivations here. First, the set of "in-progress"
designs and efforts already encompasses the most hotly desired
features and initiatives. But further, stalled work can be
demotivating and confusing. When an initiative spans over several
years, it becomes harder and harder to track the current state and
to remember all of the key design constraints. This in turn hinders
participation in the Rust project and makes it harder to figure out
what is going on (see also: the goal of improving visibility into the
state of our initiatives and design efforts).

### Improve project functioning, governance, and visibility

> Organizational work is at the core of everything else that happens in the project, and above all else this seems to be the one thing we should keep improving. We’re growing fast, and our organization needs to grow with it.
>
> -- [Yoshua Wuyts](https://blog.yoshuawuyts.com/rust-2020/)

The Rust project has grown dramatically over the last few years, in every dimension:

* We have more users than ever before.
* We are seeing many more companies -- and much larger companies -- adopting Rust.
* Our organization and Rust teams have grown.

This is great news! But with this growth comes challenges.  We are
finding that it is harder and harder to ensure communication across
the organization. It can often be challenging to find enough people to
do the work we would like to get done, which in turn leads to burnout
or people leaving the project. We've identified three major goals that
we think will help.

#### Improve visibility into the state of initiatives and design efforts

Right now it is very difficult to answer questions like "what are the
active efforts and how can I help" to "what is the status of feature
X". This is true both for folks who are deeply embedded in the Rust
organization and for newcomers.

There are many ways to improve visibility, but the most basic step is
simply expending more effort on posting updates and documenting the
status.  Things like the Inside Rust blog are helpful here, and we
should look for other ways to incorporate lightweight status updates
into our workflows.

There are a number of possible sources for this information today, such as
feature gate labels and tracking implementation history in tracking issues. Most
of these have not been formally introduced to all teams nor have they been
described in any particular nature; this experimentation has yielded mostly
positive results. However, it does not do a good job of targeting end-users who
have never visited the Rust issue tracker. We want to actively target community
members who are not actively involved in the teams. In doing so, we should also
avoid increasing the busywork factor on teams.

It has been noted by multiple team members that even those who are *very*
involved in the project (core team members, for example) frequently note that
they also do not have a good sense of the current project goals and priorities.
So we are also not meeting the needs for team members to stay up to date with
current initiatives.

There is clearly room to innovate on both fronts, and existing experimentation
should also not be overlooked.

#### Increase mentoring, leadership, and organizational bandwidth

One common challenge for us is that we seem to lack enough people to
get the work done that we would like to get done. But what we're
missing is not just *any* people, it's people who can help to do the
"leadership" work that knits the project together.

This work takes many forms. Sometimes it is technical, such as writing
mentoring instructions on issues, but more often it is organizational,
such as running meetings, posting blog posts (see the previous point),
or making plans.

We have made great progress over the years by intentionally focusing
on the "on-ramp" to contribution, through efforts like tagging E-easy
issues. We've made more limited progress on helping people "step up"
towards leadership roles.

Part of the problem here is money. One of the biggest challenges
around organizational work is that it is quite demanding in terms of
time. It requires availability. It is difficult to do in your spare
time. Therefore, helping to ensure that it is easier for people to get
paid for their work on Rust -- and especially their **organizational**
work -- is one way we might make progress here.

However, it's worth emphasizing that this doesn't necessarily mean
people whose job description is *solely* to work on Rust. There are
many companies using Rust, and many of them would like to help out,
but we need to do better at harnessing and directing those efforts.
As Parity put it in their #rust2020 post:

> “We, too, have team members who are interested in helping on
> specialization or fixing the aforementioned bugs. However, it’s
> often unclear whether the work is worthwhile. To a business, it is
> hard to argue that one might spend a month or two working on a new
> feature without any assurance that the approach taken would be
> accepted.”
>
> -- [Benjamin Kampmann, speaking for Parity](https://www.parity.io/rust-2020/)

#### Make design discussions more productive and less exhausting

> An RFC, or "request for comments" is a mechanism by which a group of
> people can get feedback from a wider community on proposed
> changes. The idea is that a written proposal outlines a change's
> scope, implementation details, rationale and impact on the
> ecosystem, then people make comments on the proposal. Usually by the
> time that everybody has stopped shouting at each other, the RFC is
> ready to be merged, meaning it is accepted and its vision can be
> implemented. This can either be implementing a feature, or removing
> unstable flags from it.
>
> -- [spacekookie](https://spacekookie.de/blog/rust-2020-the-rfc-process-and-distributions/)

The RFC process has been a crucial part of Rust's organization for a
long time. The process of documenting and talking over our designs is
often very helpful for improving the design and sometimes leads to
dramatic changes. Many other languages have adopted RFCs and
explicitly cited Rust as precedent.

Of course, we also have ample evidence that the RFC process as
presently practiced does not work well for larger-scale or
controversial designs. Last year we put a lot of energy into thinking
about techniques for improving the process, and this year we need to
put more of that energy into actually making those changes.

## Yearly calendar

Here is a rough calendar of major events in the planning of Rust. Note
that we have attempted to move up some of the Rust 2021 planning --
e.g., the survey, edition, and so forth -- so that they begin earlier
in 2020, versus the timing from this year.

* January
  * Rust 2019 survey results published
  * Roadmap RFC opened
* February
* March
  * Publish progress report, with emphasis on linking/identifying team plans for
    matching up to roadmap goals
* April
* May
* June
  * Publish progress report, describing what work we have done so
    far towards the goals of this roadmap
  * Identify more fine-grained deadlines for 2021 edition work. Schedule
    internal meetings in teams for July to verify progress.
* July
* August
  * Start organizing 2020 Rust survey
* September
  * 2020 Rust survey goes live and runs for two weeks
  * Analysis of 2020 Rust survey data begins
* October:
  * Publish survey results
  * All 2021 edition work must be landed
  * Call for Rust 2021 blog posts begins here
  * Begin work on retrospective
* November
  * Publish retrospective on what has happened over 2020
* December -- holiday month, things traditionally run slowly here

## Drawbacks
[drawbacks]: #drawbacks

One concern that has come up this year in particular is that we frequently do
not "tie" efforts actively to goals established in past roadmaps. This is one
reason that this year's roadmap is specifically intended to be much more high
level, with the fine grained details left up to the individual teams and the
community to decide upon.

## Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives

The roadmap this year is different in structure than prior years.  In
particular, we have avoided setting precise goals, in favor of
describing more general mandates and themes.

We chose to take this approach for a few reasons:

* The roadmap RFC doesn't seem like an appropriate place to make
  decisions on specific solutions. Those should be discussed in their
  own, dedicated RFCs.
* We wanted to encourage teams and project members to think about how these
  mandates apply best to the particular questions that they are working with.

However, there are some clear downsides. In particular, the goals we
have chosen are not the sort of goal that one can "complete". Clearly,
for example, the structure of the organization will always be open to
improvement, and there will always be a need to follow-through on
goals.

Our expectation is that, over the course of the year, we will relate
our concrete actions to these goals and -- in the form of a
retrospective -- try to relate what progress we have made (or not
made, as the case may be).

### Frequently asked questions

*This list contains questions that were raised during pre-discussion
of the RFC. We expect to grow the list with more questions raised
during the actual RFC discussion.*

#### What about a Rust foundation?

It seems likely that we will pursue creating a Rust foundation this
year, perhaps along the lines that [nikomatsakis described in a recent
blog post][bpf]. We opted not to include that as a "line item" in this
RFC because we were generally trying not to describe specific solutions,
but more to describe the goals that we should be working towards. Any
effort to create a foundation would fit well under "Improve project
functioning and governance", however.

[bpf]: http://smallcultfollowing.com/babysteps/blog/2020/01/09/towards-a-rust-foundation/

#### What about const generics, async I/O, cargo features, etc?

These are all examples of "in-progress designs and efforts" that
likely make sense for us to pursue. We leave the finer-grained
decision making efforts up to the teams themselves or to follow-up
RFCs where appropriate.

## Prior art
[prior-art]: #prior-art

Not applicable.

## Unresolved questions
[unresolved-questions]: #unresolved-questions

Not applicable: this section is ordinarily used to identify things to
be figured out as the work proceeds, which doesn't really apply here.

## Future possibilities
[future-possibilities]: #future-possibilities

Not applicable.
