core (roadmap)
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:
Every year, the Rust project plans out a roadmap, in accordance with RFC 1728. The goal of the roadmap is to
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:
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.
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.
We have laid out three 'major goals' for Rust in 2020:
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.
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:
&raw form proposed in RFC 2582.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.
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
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).
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
The Rust project has grown dramatically over the last few years, in every dimension:
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.
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.
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.”
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
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.
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.
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.
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:
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).
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.
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. 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.
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.
Not applicable.
Not applicable: this section is ordinarily used to identify things to be figured out as the work proceeds, which doesn't really apply here.
Not applicable.