- Feature Name: N/A
- Start Date: 2018-01-23
- RFC PR: rust-lang/rfcs#2314
- Rust Issue: N/A
This RFC sets the Rust 2018 Roadmap, in accordance with RFC 1728. This year's goals are:
- Ship an edition release: Rust 2018.
- Build resources for intermediate Rustaceans.
- Connect and empower Rust’s global community.
- Grow Rust’s teams and new leaders within them.
In pursuing these goals, we will focus particularly on four target domains for Rust:
- Network services.
- CLI apps.
- Embedded devices.
This proposal is a synthesis drawing from several sources:
- The 2017 survey.
- Nearly 100 blog posts written in response to our call for roadmap thoughts; these posts are quoted liberally throughout the RFC.
- The core team’s overall sense of the zeitgeist and project management.
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.
I believe that Rust has the potential to be an exceptionally empowering technology for people writing programs. I am trying to focus on providing the ‘last mile’ of user experience to take the core technological achievements of Rust and make them generally ergonomic and usable by working programmers. (@withoutboats)
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:
- Network services. The predominant domain for current production usage.
- WebAssembly. An emerging market where Rust is strongly positioned for success.
- CLI apps. A place where Rust’s portability, reliability, and ergonomics come together to great effect.
- Embedded devices. A domain with a great deal of potential that is not yet first-class.
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
constgenerics), 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:
I’d like to reach a final decision to ship or drop all of the ergonomics RFCs that were accepted. I hope to see this completed over the next several months . . . I hope we can have a clearer (and more spaced out) schedule for this so that their FCPs are staggered. (@withoutboats)
Among these productivity features are a few “headliners” that will form the backbone of the release:
- Non-lexical lifetimes. Currently in “alpha” state on nightly, with work ongoing.
impl Trait. Nearing readiness for stabilization FCP.
- Generators. “Beta” state on nightly, but some design issues need resolution.
- Module system changes. Largely usable on nightly; will need testing, feedback, and bikeshedding.
In addition, there are some other headlining features which are nearing stabilization and should ship prior to the edition:
- SIMD. The core SIMD intrinsics are nearing readiness for stabilization, and with luck we may be able to stabilize some vendor-agnostic primitives as well.
- Custom allocators. The machinery has been in place for some time. Let's settle the details and ship.
- Macros 2.0. This feature is implemented and working, but stabilization will require us to reach a comfort level with the handling of hygiene and a few other core issues.
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):
- Generic associated types. This feature will almost certainly land in nightly in 2018, and may even stabilize during the year. However, enough implementation work remains that it’s unlikely to be stable prior to the edition release.
- Specialization. Stabilization is blocked on a number of extremely subtle issues, including a revamp of the trait system and finding a route to soundness. We cannot afford to spend time on these issues until after the edition release ships.
- const generics. This feature is likely to land in nightly in 2018, but will not be ready to stabilize this year given the substantial work that remains.
Give me non-embarassing compilation speed! (@matthewkmayer)
Compiler work will center on:
- A steady focus on compiler performance leading up to the edition release. We will pursue two strategies in parallel: continuing to push incremental recompilation into earlier stages of the compiler, but also looking for general improvements that help even with from-scratch compilation. For the latter, avenues include compiler parallelization and MIR-only rlibs, amongst others. We will formulate a comprehensive set of compilation scenarios and corresponding benchmarks and set targets for the edition release (see the tracking issue for some details). Finally, we will spin up a dedicated Compiler Performance Working Group to focus on this area.
- Completing and polishing the language features mentioned above.
- Another push on improving error messages.
- Edition tooling: adding an edition flag and building
rustfix, likely by leveraging lints.
In preparation for the edition release, we will continue to invest in Rust’s library ecosystem in three ways:
- Quality. Building on our 2017 work, we will bring the API Guidelines to a 1.0 status and build out additional resources to aid library authors.
- Discoverability. We will continue to work with the crates.io team on discoverability improvements, as well as push the Cookbook (or something like it) to 1.0 status as a means of discovering libraries.
- Domain-specific content. We will work with library authors in the four domains of focus this year to sharpen our offerings in each domain (elaborated more below).
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:
- Resources for intermediate Rustaceans. This topic is covered in detail below. It’s possible that some of these resources will be ready to go by the edition release.
- Overhauled rustdoc. There’s ongoing work on an RLS-based edition of rustdoc with internationalization support, and the ability to seamlessly integrate “guide” and “reference”-style documentation. As a stretch goal for the edition, we could aim to have this shipped and major libraries using it to provide a better documentation experience.
As part of the Rust 2018 edition release, we will:
- Ship 1.0 editions of the RLS and
rustfmt, distributed via
- Distribute Clippy via
- Stabilize custom registries for Cargo.
- Implement and stabilize public dependencies in Cargo.
- Revise Cargo profiles.
Beyond these clear-cut items, there are a number of ongoing efforts, some of which may ship as part of the edition:
- Xargo/Cargo integration. Alternatively, this can be viewed as allowing
stdto 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).
- Build system integration improvements. Seek to incrementally deliver on the work laid out in 2017. It’s unclear what pieces might be ready for stabilization prior to the edition release.
And a couple of goals that are probably a stretch for 2018 at all, let alone for the edition release:
- Custom test frameworks. There’s been a lot of interest in this area, and it may be possible that with a dedicated working group we can implement and stabilize test frameworks in 2018.
- Compiler-driven code completion for the RLS. Today the RLS still uses a purely heuristic approach for auto-completion. If the compiler’s new “query-based” architecture can be pushed far enough during the year, it maybe become feasible to start using it to deliver precise auto-complete information.
Many, many of the #Rust2018 posts talked about improving our web presence and the marketing therein:
Having a consistent, approachable, discoverable, and well designed web presence makes it easier for visitors to find what they’re looking for and adds signals of credibility, attention to detail, and production readiness to the project. (@wezm)
As part of the 2018 edition release, we will completely overhaul the main Rust web site with:
- A new, striking visual design, which will eventually be used across all of our web sites (including crates.io).
- Vastly improved marketing materials, including dedicated pages for all four of this year’s “user stories”.
- Much more extensive resources useful for being productive with Rust, e.g. dedicated pages for Rust’s tooling story that make it easy to discover the state of the art and choose the best tools for you. Also links to various media resources (videos etc.)
This includes discussions on how to structure big projects in Rust and Rust-specific design patterns. I want to read more about professional Rust usage and see case-studies from various industries. (@mre)
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.
Mentorship does a lot to help underrepresented groups of people. (@blackdjikstra)
Rust is very new and most of the documentation coming out is probably going to be in English because it is the most widely used language. However, we have to acknowledge that we don’t only have english speakers in the rust community and it would be great if some of the text was translated to accommodate non English speakers. (@blackdjikstra)
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:
- Clearly defined processes for engaging with, joining, and growing one’s role within the team
- Onboarded new members from communities around the world
- Grown existing members into leaders of new and existing initiatives
- Run, supported, and/or facilitated events in a diverse set of communities, including industry trade fairs, colleges and universities, and geographic locations that are currently underserved by technical events
- Expanded accessibility of Rust resources (including Internationalization!)
- Organized data for assessing and analysing progress on the above goals
You can read more about these goals in the [2018 Community Team Goals RFC](link needed).
Initiatives like the libz blitz put the libs team within the community and put the community within the libs team. I think the shared sense of ownership over the Rust project is what keeps it moving forward. (@kodraus)
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)
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.
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 is a fantastic language for writing a Command Line Application (CLI). For the ergonomics of hacking, it has one of the best argument parsers ever, has seriously the best serialization library ever and it compiles to almost any target and goes fast when it runs. (@vitiral)
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!
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
Check out @japaric’s roadmap for a plausible way forward.
I want to see  as an extended impl period. (@Manishearth)
The remainder of the year will be broken up into four chunks:
- Feb — Mar: Design and early work.
- Apr — July: Buckling down.
- Aug — Nov: Fun!
- August 2: Edition in beta
- September 13: Edition released
- Dec — EOY: Reflection.
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:
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:
- Scientific/numeric computing
- Machine learning
- Big data
- Traditional mobile apps
- Traditional desktop apps
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:
- They represent clear, significant near-term market impact for Rust.
- They already have significant momentum, making it viable to achieve that impact with our 2018 work.
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:
I’d like to see a stronger focus [on] mentoring. (@manishearth)
growth and outreach:
Rust should actively be seeking out diversity. (@softprops)
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.