core (roadmap)
This RFC sets the Rust 2018 Roadmap, in accordance with RFC 1728. This year's goals are:
In pursuing these goals, we will focus particularly on four target domains for Rust:
This proposal is a synthesis drawing from several sources:
The motivation and detailed rationale of each piece of the roadmap proposal is explained in-line throughout the RFC; the closing section covers the high-level rationale.
This year will be a focused one for the Rust community, with two overall technical goals, and two social ones. Here we’ll give a brief overview of each goal and some overarching themes, and in the Reference section below we’ll provide full detail.
Ship Rust 2018. We will ship a major marketing (edition) release in the final third of the year, with the unifying message of productivity. We will continue to focus on compiler performance, both from-scratch and incremental rebuilds. We will polish and stabilize a number of already-implemented language features like impl Trait, macros 2.0, SIMD, generators, non-lexical lifetimes and the modules revamp—and very few new ones. We will also drive critical tools (like the RLS and rustfmt), libraries, and documentation to 1.0 status. We will overhaul the http://rust-lang.org/ site to help market the release and to support programmer productivity.
Build resources for intermediate Rustaceans. We will write documentation and build examples that help programmers go from basic knowledge of Rust’s mechanics to knowing how to wield it effectively.
Connect and empower Rust's global community. We will pursue internationalization as a first-class concern, and proactively work to build ties between Rust subcommunities currently separated by location or region. We will spin up and support Rust events worldwide, including further growth of the RustBridge program.
Grow Rust's teams and new leaders within them. We will refactor the Rust team structure to support more scale, agility, and leadership growth. We will systematically invest in mentoring, both by creating more on-ramp resources and through direct mentorship relationships.
To make our product successful, we should build and market it with an eye toward specific user stories, ensuring that we have a coherent and compelling end-to-end experience. Thus, investment in ecosystem, marketing, and feature prioritization will emphasize the following four domains in 2018:
Looking at the year as a whole, with our second marketing release of Rust, @nrc perhaps put it best:
The Rust edition 2018 release encompasses every aspect of the work we do, so we’ll look at each area in turn. This RFC is not intended as a promise about what will ship, but rather a strong (and realistic) intention. The core team will ultimately oversee the precise timing and feature set of the release.
It’s important to keep in mind two additional factors:
“Shipping” features in this context means they must be stable. We may land additional unstable features this year (like const generics), but these are separate from the Rust 2018 product. We will stabilize features individually as they become ready, not in a rush before the edition release.
The intent is to ship Rust 2018 in the latter part of the year. The tentative target date is the 1.29 release, which goes into beta on 2018-08-02 and ships on 2018-09-13. That gives us approximately six months to put the product together.
These two factors together suggest that Rust 2018 will ship largely with language features that are already in nightly in some form today. Other, faster-moving areas of the product will be developing new material throughout the year.
As always, we will continue to push out new Rust releases on a six week cadence, so a given feature missing the edition release is by no means fatal. On the other hand, we need to carefully coordinate the work so that the features we do ship sit together coherently across the compiler, tools, documentation, libraries and marketing materials.
Rust 2018: Consolidation (@killercup)
The most prominent language work in the pipeline stems from 2017’s ergonomics initiative. Almost all of the accepted RFCs from the initiative are available on nightly, but polish, testing, and consensus work will take time:
Among these productivity features are a few “headliners” that will form the backbone of the release:
impl Trait. Nearing readiness for stabilization FCP.In addition, there are some other headlining features which are nearing stabilization and should ship prior to the edition:
Between generators and macros 2.0, we will have some support for async/await on stable Rust (possibly using macros, possibly some other way).
Finally, there are several highly-awaited features that are unlikely to ship in the Rust 2018 edition release (though they may ship later in the year):
Give me non-embarassing compilation speed! (@matthewkmayer)
Compiler work will center on:
rustfix, likely by leveraging lints.We need more 1.0 production-ready crates to get people productive. (@killercup)
The core team should participate in prioritizing and implementing quality crates for productivity needs. (@nimtiazm)
In preparation for the edition release, we will continue to invest in Rust’s library ecosystem in three ways:
Documentation plays a critical role in the edition release, as it’s often an entry point for people who are taking a look at Rust thanks to our marketing push. With regards to the edition specifically, this mostly means updating the online version of “The Rust Programming Language” to include all of the new things that are being stabilized in the first part of the year.
We’ll also be doing a lot of work on Rust By Example. This resource is both critical for our users and also slightly neglected; we’re starting to put together a small team to give it some love, and so we hope to improve it significantly from there.
There are two additional areas of vital documentation work for 2018, which are not necessarily tied to the edition release:
As part of the Rust 2018 edition release, we will:
rustfmt, distributed via rustup.rustup.Beyond these clear-cut items, there are a number of ongoing efforts, some of which may ship as part of the edition:
std to be treated as an explicit dependency in Cargo, which has long been a requested feature and which is very helpful for cross-compilation (and hence for embedded device work).And a couple of goals that are probably a stretch for 2018 at all, let alone for the edition release:
Many, many of the #Rust2018 posts talked about improving our web presence and the marketing therein:
Goal 2: Explain on rust-lang.org who the Rust programming language is for (@jvns)
Promote Rust as a language that makes large codebases maintainable. (@killercup)
I suggest in 2018, we kick the idea of wrestling with the Rust compiler to the curb and focus on how it helps us rather than the idea of it beating us down. (@jonathandturner)
As part of the 2018 edition release, we will completely overhaul the main Rust web site with:
One of the strongest messages we’ve heard from production users, and the 2017 survey, is that people need more resources to take them from understanding Rust’s concepts to knowing how to use them effectively. This roadmap will not stipulate exactly what these resources should look like — probably there should be several kinds — but commits us as a community to putting significant work into this space, and ending the year with some solid new material.
The post by QuietMisdreavus offers a wealth of ideas.
We should ask how to improve support for local meetups to strengthen community cohesion. (@llogiq)
Mentorship does a lot to help underrepresented groups of people. (@blackdjikstra)
“What can I, or other people not one the core team, do to help stabilize Rust?” (willmurphyscode)
This year's community team focus is building capacity by growing leaders and empowering new communities. At a high level, by the end of 2018, the Rust Community Team should have:
You can read more about these goals in the [2018 Community Team Goals RFC](link needed).
We need to Think Big when it comes to Rust’s teams. (@aturon)
Last year saw a lot of growth in Rust’s teams, and we’ll need to keep that up in 2018 if we want to accomplish everything we’ve set out above! To do that, we will:
Revise the subteam structure by breaking up and delegating tasks from the current teams to new teams that they manage, as appropriate. This will allow us to expand the number of people working on the teams overall, while keeping each team at a manageable size. So, for example, the Libs Team can form child teams dedicated to std, API guidelines, discoverability, and more. Also, as with the impl Period, we will feel more free to spin up “working groups” to target some specific concern, often with a clear-cut end goal. This RFC creates a few such working groups; other team changes will be decided on and announced by the relevant teams.
Create more contributor resources, like the new book focused on compiler contribution.
Systematize mentoring, by improving tools like findwork and developing best practices for mentoring across teams.
With many of the goals listed above, we have some choice about what use-cases to focus on. To help ensure that our Rust 2018 product has a coherent story, we will focus on four target markets that have either already seen Rust uptake, or where we believe that Rust has significant potential.
We will spin up a separate working group for each of these domains, reporting to the core team, and tasked with looking after the end-to-end experience in that domain and making recommendations to other Rust teams with decision-making power.
I think network services are a great opportunity for Rust. (@withoutboats)
I think it’s very important - especially for network programming - to see generators and async/await stabilized in Rust. (@withoutboats)
Tokio needs a lot of work. (@nicoburns)
Rust sees heavy production use in the network services domain, both in implementing services directly and in providing related infrastructure. The domain was also a major focus in 2017. This year, we will push hard on making the end-to-end user experience in this domain solid and stable.
I believe that WebAssembly is about to take off in a big way. (@djc)
We're poised to be THE language of choice for wasm. (@mgattozzi)
Late in 2017 we added the “wasm32-unknown-unknown” target, making it possible to emit pure WebAssembly binaries from Rust, without any extra toolchain hassle. The interest has been explosive, with some JS bundlers now offering Rust support out of the box. This is a brand new market with no incumbent and for which Rust is extremely well-positioned (read @mgattozzi’s excellent post for a comprehensive argument). We will work this year to make integration, tooling, and the library ecosystem as polished as we can manage. An informal working group is already coordinating on GitHub.
Rust has also seen some production update in the CLI space, for which it is very well-suited. This is a space where Rust’s portability, reliability, and ability to produce static binaries make it extremely attractive. We also have a number of excellent libraries already. This year, we will improve this ecosystem and pull it together into a polished, coherent package for people checking out Rust. Read @vitiral’s post and @killercup’s crate for some inspiration!
In 2018, I simply wish [the embedded community] could switch to beta or even stable! (Pierre Rouanet)
I'd also like to see the core team think a little more about #[no_std] development.
Let's make 2018 the year Embedded Rust goes mainstream! (@thejpster)
There’s always been simmering excitement around using Rust in the “bare metal” space, but among the domains we want to target, it’s needed the most work in terms of language features to fully support. While we cannot hope to stabilize everything needed for embedded development in 2018, we can step up our game and begin to treat the market as more mainstream. This intersects nicely with the WebAssembly work, since WebAssembly presents a very barebones machine model and will thus interact deeply with the no_std ecosystem.
Check out @japaric’s roadmap for a plausible way forward.
I want to see [2018] as an extended impl period. (@Manishearth)
The remainder of the year will be broken up into four chunks:
Design and early work. Coming off of the impl period, for the start of this year we’ll take some time to process RFCs, to plan, and to spike any late-breaking design ideas that could possibly ship in the Rust 2018 edition release. We will, of course, continue to push on implementation and stabilization work at the same time. By the end of this period, we should have a very clear picture of what we will ship in the edition, and what needs to happen to do that.
This period culminates with the Rust Team All Hands in Berlin at the end of March.
Buckling down. Structured much like the impl period, we will be laser-focused on making the edition release as good as it can be. It will be a community-wide effort. Little to no design or RFC work will happen during this time. RustFest Paris and a Mozilla all-hands will happen during this time, and we will likely try to host “impl days” similar to last year.
This period culminates with cutting the beta edition release at the beginning of August, with RustConf following shortly after.
Fun! Having pushed hard up to this point, for the remainder of the year we will relax our tight focus and allow for more exploration, as well as work on fun features like const generics, GATs, and specialization. Rust Belt Rust will happen during this period.
Reflection. We’ll leave the month at the end of the year for retrospectives and 2019 planning, with the hope that we can start 2019 with a roadmap already in place.
Here’s a high level rationale for the two major themes this year: shipping and community.
The data and discussion quickly coalesced around one of the basic contours for this year: a sense that a lot of important improvements are in the pipeline, and what’s needed this year is a strong focus on shipping. As @nikomatsakis put it:
We did good work in 2017: now we have to make sure the world knows it and can use it. (@nikomatsakis)
Or, in @nrc’s more provocative phrasing:
I want 2018 to be boring. (@nrc)
This sentiment is the foundation for this year’s technical work, and there’s a striking similarity to the spirit leading up to Rust 1.0. While shipping what’s already in our pipeline may be “boring”, it’s not easy. One of the hardest challenges for us as a community is the same one we faced with 1.0, one that @skade voiced succinctly:
Shipping requires the discipline to say “no” to exciting new ideas, and to say “yes” to delivering on ones we fear are flawed. We have to iterate toward perfection, providing useful snapshots along the way.
One particular aspect of focusing on shipping a polished product this year was saying "no" to some usage domains. In particular, we are not aiming for a polished story in any of the following domains in 2018:
While these targets are all of potential interest for Rust, the ones we chose to target in the 2018 roadmap all have two important traits:
Of course, some of the foundational work like const generics that we plan to do in 2018 will be important for some of the domains listed above. But the point is that the roadmap pinpoints four domains for a solid end-to-end experience.
Our work in 2017, especially during the impl period, was the clear result of a community-wide effort. To do the hard work of “polishing new things into great things,“ and to keep up with Rust’s continuing growth, we need to double down on our investment in our community. That’s a theme with several facets, including project leadership:
continued mentoring:
I’d like to see a stronger focus [on] mentoring. (@manishearth)
growth and outreach:
Rust should actively be seeking out diversity. (@softprops)
While we talk about “the Rust community”, the reality is that there are many Rust communities, separated by geography and by language. We need to do much more to connect these communities.(@aturon)
and corporate involvement:
I’m also hoping for more companies to invest back into Rust. (@manishearth)
That’s a lot! But it’s work that immediately pays dividends back into the project, both in terms of adoption and development.
TBD