Rust 2018

Instead of fireflowers, this year the Rust Team made a public call for blogposts, asking the community to write posts that reflect on Rust in 2017 and what they wish for Rust in 2018. What follows are some of the things I personally see as important, and that I'd love to prioritize on in the following months.

As another Pascal wrote, if I had more time, I'd have written a shorter blog post. So this is more a collection of thoughts and ideas than a polished roadmap proposal.

Rust 2017

But first, let us look back at the last year of Rust. 2017 was a year in which the Rust project made some great steps forwards. To pick a few:

• The first-ever roadmap RFC was used as a driving force to focus on specific areas of improvement, and a lot of RFCs were written and discussed (from my subjective viewpoint, a lot of discussion was around the ergonomics initiative).
• Four Rust conferences took place. I went to the two RustFests in Kyiv and Zürich and really loved how enthusiastic everyone was!
• The dev tools team was formed – with me as a member – and discussed a number of diverse topics from the next version of rustdoc, the future of rustup components (clippy and rustfmt, yay!), to testing frameworks (very recent). This teams also has a set of "dev tool peers", who experts in specific fields (and who in contrast to the core members only join some of the meetings).
• The first-ever "impl period" took place, where from September to the end of the year a lot of (new!) people helped with implementing and stabilizing features (i.e., focus on implementing stuff instead of writing new RFCs).

Rust 2018: Consolidation

Nick Cameron wrote a really good "Rust 2018" post already, asking us to keep 2018 "boring":

I would like 2018 to be a year of consolidation on 2017's gains, of paying down technical debt, and polishing new things into great things. More generally, we could think of a tick-tock cadence to Rust's evolution - 2015 and 2017 were years with lots of big, new things, 2016 and 2018 should be consolidation years.

This is something I can agree with -- there are a lot of project that are ongoing and I would love to see them become usable by a lot of people.

Rapidly reduce the number of in-flight unstable features.

The unstable book currently lists 113 language features and 155 library features. I think a lot of people have a few favorite features they've been waiting for. In fact, I asked just this question at the Rust Cologne meetup yesterday, and – in addition to a great discussion about some of the features – was reminded of some features whose RFC I've read years ago, but that have not landed yet.

I believe that a lot of these features are not inherently complex, it just takes a lot of time and concentration to get them to a state where the team is confident that they can be stabilized. I would love to see a team formed that, similar to the libz blitz initiative, focuses on stabilizing features. I think that by having a team that helps set the stage for a stabilization (by getting blockers out of the way, by documenting the precise requirements and process that it takes to stabilize each feature, and by offering mentoring and guidance), short-lived strike teams tackling singular features will become viable. I think something like this is often already happening implicitly, but having an official initiative will hopefully invite new people and making this scale a bit better.

Just for the record, here are some of my favorite unstable features:

• try_from
• (advanced_)slice_patterns
• associated_type_defaults
• const_fn (and const_indexing) – even if this is very conservative at first, let's get this miri goodness to the people!
• (conservative_)impl_trait
• generators
• and of course proc_macro

Update: Relevant thread on Twitter (started by Manish). Also, I propose to call this effort to form small teams to stabilize features "Rust Stabilization Meta Strike-Force". It should, however, only be written in its abbreviated form (RuStMeS).

Continue doing and promote foundational work.

In addition to the concrete features listed above, I know of some projects that are more about foundational work and that enable a whole set of new features to be worked on. Just like MIR, a refactoring of the compiler that happened over the last years, whose goal was to pay off technical debt in the rustc codebase and to enable better codegen with custom optimizations, the quest for incremental compilation has cause a lot of work has been done in the last year to make the compiler more "queryable". These efforts, as well as many others, are fundamental improvements that not just increase the productivity of people implementing features but hopefully also prevent people from no longer contributing (because they are frustrated with the code base) as well as invite new contributors that are looking for "applied computer science" work.

(I have to admit: I'm a huge fan on Niko Matsakis' blog (his articles on Chalk are amazing), and would love to see more people talking and writing about the theoretical aspects of Rust!)

Provide a way to quickly find where you can help out and get mentoring.

There are some huge RFCs that have been approved but there is no implementation going on right now. Also, there are some great efforts that exist outside of the usual issue tracker – e.g., the super interesting stuff happening in chalk, miri, and even clippy is not that easy to find if you're a newcomer to the project.

In addition, one thing that seems to have really made the aforementioned "impl period" a success was that a lot of issues (and workgroups) had mentoring available to help people who have never interacted with the Rust project become productive real quick. Some of the open issues were collected on the "find work" page of rustaceans.org which I've personally linked to a few times. We should improve this page, and try to combine it with an overview of not only projects but also RFCs and community efforts to give newcomers and long-term community members alike a place where they can see what's happening right now and where they can help out.

Land stable development tools.

rustfmt and clippy are on their way to being available in a stable release as rustup components, and RLS is available as a preview. These are huge blockers for people who want to use stable right now, and even though I don't think it's that big of a deal to use nightly, I'd love to have these tools available to as many people as possible.

My own rustfix tool is a small shim on top of the compiler's JSON output and the huge list of clippy lints. My goal is to get a version of it that works in RLS available this quarter.

Aim for long-term stability of the library ecosystem.

The number of crates on crates.io almost doubled in 2017 – but quantity isn't everything. The libz blitz effort brought us API guidelines as well as improvements to a bunch of crates (cf. the Rust 2017 roadmap review post), some of which have had 1.0 releases.

Update: Aaron published a post about Retooling the Rust Libs Team team for 2018 which touches some of the points discussed here but from the perspective of the libs team.

Community-maintained crates

I really want to see this effort continued, but I also want it to be expanded. I don't have a concrete proposal how to get this going right now, but I'd love to see more community-maintained crates.

There is no reason why so many popular crates should live in user-repos instead of in community-managed organizations (speaking in Github terms). Writing and then publishing a bunch of code as a crate one thing, but maintaining it, fixing bugs, replying to issues and pull requests, that takes up a lot of time as well. Time, that a lot of developers don't have, or don't want to invest. cargo-edit, for example, which lives under my Github username, has two wonderful maintainers, who are more active than I am. But should I create a cargo-edit organization and move the repo there? If there was a good and definitive answer, which would neither make me deal with the organizational aspects not result in accumulating lot of junk code, I'd be really happy.

This is also a people problem. To establish Rust as an established language in the industry and to deliver and maintain production ready crates, we need full-time developers who can act as team leaders and maintainers for community-owned crates. And the next question is: Who pays these people[^like-me] to work on open source and Rust for a large segment of their work time?

[^like-me]: cough Did I mention I'm a freelancer with lots of Rust experience? cough

Up