In January of this year, we adopted the 2017 Rust Roadmap, which laid out our plans for 2017. Now that 2017 is roughly half over, we thought we would check in on our progress in each of our roadmap areas thus far. In addition to talking about what's been going on, we'll also include some notes on how you can get involved.

Tracking progress on the roadmap

First, a meta note. If you'd like to follow along with the progress on a particular roadmap initiative, or to find out more about how you can get involved, the best place to go is the list of issues on the rust-roadmap repo. There you will find an issue dedicated to each of the major initiatives that we are pushing on. These issues contain links to ongoing work. You'll find a number of links to issues like this in the descriptions that follow.

Rust should have a lower learning curve

The most direct way to make Rust easier to learn is to improve the way that we teach it. To that end, we've been hard at work on a brand new edition of the "Rust" book (roadmap issue), and we now have a complete draft available online. This new edition puts ownership front and center and it also has expanded coverage of a number of other areas in Rust, such as error handling, testing, matching, modules, and more. Even better, you can pre-order a printed version through No Starch Press. If you'd like to help out, there is still lots of editing work to be done!

We've also been working on a number of languages changes aimed at improving language ergonomics. These range from long-standing proposals, like non-lexical lifetimes or impl Trait, to newer ideas, like the recently approved RFCs on trait aliases the match ergonomics. On the roadmap issue, you will find a large list of initiatives, organized by the part of the language that they target (e.g., ownwership/borrowing, the trait system, etc). We are actively looking for people to help with writing RFCs but also implementing the accepted RFCs -- if you're interested in helping out with something, look for the "mentoring" contacts listed in the roadmap issue or on the tracking issue for a specific RFC. And, of course, if you think you've got a good idea that's not listed, open up a thread on internals and let's talk about it!

Rust should have a pleasant edit-compile-debug cycle

We've been targeting the problem of improving compiler performance in a number of different ways. One of the simplest is the cargo check command that we released in Rust 1.16 -- this command does a limited form of compilation which skips code-generation and simply looks for type-errors. Since code generation typically takes 50% of more of compilation time, this can be really useful in the early stages when you are writing new code and trying to get it to compile, particularly if you have a multi-crate project. This command is also used by the RLS.

Of course, eventually you want to run your code, and for that you need a full compilation. In order to make that faster, we've been hard at work retooling the compiler to work in an incremental fashion. Earlier this year, we advertised the "beta" release of incremental on nightly builds. While the beta version sometimes achieved quite large speedups, we also found that the dependency tracking not as robust or effective as we would like. Therefore, we are now adopting a revised approach to incremental compilation, which we call the "red-green algorithm" (I prefer "the salsa algorithm", but that has never caught on). We expect to be switching over to this new system in next month or two, which should mean that we will see much better incremental performance shortly thereafter. If you're interested in helping with the transition to the new system, check out the incremental compilation roadmap issue or the tracking issue for the red-green algorithm itself; you can also follow this internals thread, where we regularly post links to bugs that include mentoring instructions.

Looking beyond incremental compilation, we've also been taking steps to optimize compilation time in other ways. Probably the most important step in that respect has been getting a new version of the perf.rust-lang.org website up and running. The "perf" website tracks the effect of each and every PR on compilation performance, so that we can detect and correct regressions. In fact, the new website immediately led to some major performance improvements. There is still lots of work that could be done to improve it, however, ranging from evaluating and improving our benchmark suite to improving the web interface; see the tracking issue on this topic for more.

Rust should provide a solid, but basic IDE experience

Since it first debuted at RustConf last year, the Rust Language Service (RLS) has been growing rapidly (roadmap issue). It now offers support for most basic IDE operations, such as "jump to definition" or "find all uses", as well as offering code completion (via the racer project) and some refactorings. At this point, the focus is primarily on polish: making the RLS easier to install and fixing bugs. For example, we recently made it possible to install the RLS directly through rustup.

If you'd like to give the RLS a spin, the easiest way is to use the VSCode plugin; however, the RLS is a generic server (it speaks Microsoft's Language Server Protocol), and there are also clients available for a number of other editors. A word of warning: at this point, the RLS is still in an "alpha" period. While it is eminently usable, you may encounter bugs or other limitations.

If you'd like to get involved with the RLS, check out the roadmap issue or the RLS issue listing; in particular, those things tagged with "good first issue".

Rust should provide easy access to high quality crates

As the size of the crates.io ecosystem has grown, the simple search and sorting criteria used by the crates.io website are no longer that helpful for figuring out which crates you should use. To address this, we've added categories and a number of badges that crate authors can add to their crates. These help people find crates for a particular purpose and judge a crate’s quality at a glance. In addition, RFC 1824 laid out a plan for improving the default sort in crates.io and exposing additional information to help in selecting a crate. There is a tracking issue that lists the pieces of this RFC, and we’d love contributions towards those pieces! Once the RFC is completely implemented and people have had a chance to use the features for a while, we plan to ask the community for feedback and make adjustments.

Rust should be well-equipped for writing robust servers

We've made some excellent strides the first half of this year towards making Rust well equipped for writing robust servers. The futures crate and Tokio project continue to explore the asynchronous I/O ecosystem and have seen some heavy usage through crates like Hyper and production users like linkerd-tcp. Additionally we've seen projects like Rocket continue to tirelessly push on the ergonomics of Rust-on-the-server to new frontiers. A recent discussion of what the biggest blockers are today has highlighted that async/await notation, better Tokio/futures documentation, and a solid HTTP foundation for the ecosystem are some of the next highest priorities. We plan to enable async/await notation on the nightly Rust channel by the end of the year and position it for stabilization in early 2018. This in turn should help fuel a rewrite of Tokio's/future's documentation and continue to grow community support for crates such as HTTP.

Rust should have 1.0-level crates for essential tasks

We've started a systematic effort to identify the most broadly used crates in the Rust ecosystem and to ensure that they all meet a consistent level of completeness and quality. This effort is called the Libz Blitz. Every two weeks, the libs team holds a meeting focused on a particular, widely used crate, with the crate author(s) in attendance. In that meeting, the state of the API, documentation, and other details are reviewed, and a checklist of actions that are needed before a 1.0 release is drawn up. That checklist can then be used to drive community involvement and help push the crate over the finish line. If you're interested in participating, take a look at the introductory post on the internals thread, which highlights how you can get involved in the initial evaluations, or go and find a work item from one of the crates that has already been evaluated:

• log
• reqwest
• walkdir
• error-chain

Rust should integrate easily into large build systems

There has been a lot of progress on more clearly identifying what the challenges are and developing concrete proposals that target them. We now have a pretty decent idea of what improvements are needed to ease build system integration, with buy-in from stakeholders. That includes:

• Support for using Cargo to create a build plan but not execute it
• Support declaring external dependencies in a first-class way (rather than via arbitrary build scripts as we do today)

Rust's community should provide mentoring at all levels

When it comes to mentoring, we've been pursuing a few different efforts. The first, RustBridge, is focused on building teaching and workshop materials that target people completely new to Rust. The materials have already been through several iterations and continue to evolve and improve.

In addition, the various Rust teams have been pursuing a number of different initiatives trying to encourage people to get involved in the Rust project itself:

• We've added three new teams -- infrastructure, cargo, and dev-tools -- and hence created new areas where people can get involved.
• The lang team has adopted the new shepherd role. Shepherds are experienced members of the community who have demonstrated both excellent technical acumen and the ability to build consensus and understand alternative perspectives. Shepherds attend language meetings and help to steer discussion on RFCs and guide them towards a useful conclusion.
• The lang team has also been working on "mentoring" RFCs. The roadmap issue for the ergonomics initiative, for example, lists a number of RFCs where we are actively recruiting.
• A big part of the "Libz Blitz" is helping to direct community effort to pushing libraries over the finish line.
• The compiler team has been actively pursuing "mentoring bugs" (bugs tagged as E-mentor), which include written instructions, as well as drawing up plans to improve the documentation of the code and workflows.

Other projects

Although they are not official Roadmap items, we also want to highlight a few major initiatives that have seen great progress lately. The embedded Rust initiative is doing awesome stuff XXX. Syntax extensions and plugins are cool too.

Conclusion

In conclusion, you can see that it's been a very busy six months in Rust land. I'd like to thank all the many people who have been involved in pushing these projects over the finish line!