Summary

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.
  • WebAssembly.
  • CLI apps.
  • Embedded devices.

Motivation

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.

Guide-level explanation

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:

At the end of the year I want Rust to feel like a really solid, reliable choice for people choosing a programming language. (@nrc)

Reference-level explanation

Goals

Ship Rust edition 2018

Aiming for a major product release gives us an opportunity, as a community, to come together and do something big that goes well beyond the usual six week cycle.

Releasing “Rust 2018” gives us a chance to say to the world that “Rust has taken a major step since 1.0; it’s time to take another look”. (@aturon)

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.

Language

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.

Compiler

Give me non-embarrassing 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.

Libraries

It is often stated that rust’s ecosystem is immature. While this is somewhat true, the real issue is in finding and using the pieces you need. (@vitiral)

Obviously, we cannot force people to choose one project over another, but it would be great if we could somehow focus our collective resources on fewer standard high-quality crates. (@llogiq)

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:

  • 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

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.

Tools

As part of the Rust 2018 edition release, we will:

  • Ship 1.0 editions of the RLS and rustfmt, distributed via rustup.
  • Distribute Clippy via rustup.
  • 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 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).
  • 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.

Web site

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)

Goal 2: Explain on rust-lang.org who the Rust programming language is for (@jvns)

We think it’s time to trumpet from the mountaintops what the Rust community has known for a while: Rust is production ready. (Integer 32)

We should have a polished web site that works for both engineers and CTOs, offering white papers and directing companies to sources of training, consulting, and support. (@aturon)

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:

  • 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.)

Build resources for intermediate Rustaceans

We, as a community, should work on creating the next level of learning resources to help folks deploy Rust to production with confidence. (@integer32)

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)

Once you have a grasp of what knobs do what in the language, how do you learn what’s considered “proper”, or what structures people have found to make future maintenance easier? (@QuietMisdreavus)

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.

Connect and empower Rust’s global community

“Additionally, more venues should be created to work with production users to gather regular feedback in a convenient, scalable way.” (Integer 32)

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)

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

Grow Rust’s teams and new leaders within them

I’m convinced, that by improving documentation and mentorship, we can grow the number of contributors significantly and stabilize many highly-anticipated features this year. (@mre)

We need to Think Big when it comes to Rust’s teams. (@aturon)

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.

Domains

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.

Network services

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.

WebAssembly

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.

CLI apps

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!

Embedded “bare metal” devices

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.

Schedule and structure

I want to see [2018] 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.

Rationale, drawbacks and alternatives

Here’s a high level rationale for the two major themes this year: shipping and community.

Shipping

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:

I’d like us to stabilise imperfect things. (@skade)

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.

The domains

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
  • Games
  • 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.

Community

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:

Rust is a staggeringly large project with a huge and talented community, and we need its leadership structure to reflect that if we are to reach our full potential. (@aturon)

I want the community leadership to feel like a well-functioning machine, and that the larger community feels well-represented and can trust the leadership teams. (@nrc)

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.

Unresolved questions

TBD