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¹ to work on open source and Rust for a large segment of their work time?

Update: Manish mentioned on Twitter that the rust-unofficial organization might be a good place for this.

Enlarge the stable foundation of crates.

We need more 1.0 production-ready crates to get people productive. There already are a lot of high-quality crates for specific things, e.g., regex and clap, but many “micro-ecosystems” are still in flux.

Let me give you a few examples:

There is no best-practice full-featured logging solution that is used by the majority of the community beyond the log crate.
There is an ongoing effort to establish a Tokio-/Futures-based ecosystem, with the goal of offering a stable foundation of crates that people can use to build their async I/O projects on. This has been cooking since at least early 2016, and I really hope to see the next iteration of this.
With hyper, reqwest, http (defines HTTP1 types) we have some crates that could become the de-facto standard HTTP crates, but they are not there yet.
There are two very popular crates that try to make error handling more ergonomic, error-chain, and the very new failure. The fact that failure was only introduced a few months ago but is already getting a lot of traction shows that this is an area that has not yet settled down.
Some good news at the end: The serialization/deserialization story is basically done with serde 1.0! I’m sure there are a lot of open issues and a lot of format-specific adapters still need to be written, but using serde is one of the best experiences you can currently have in the Rust ecosystem.

Promote Rust as a language that makes large codebases maintainable.

While I only know of anecdotes that support this (I’d love to see studies on this), I’m pretty convinced Rust is a very good language for codebases with tens or hundreds of thousands of lines of code. It’s not just the strict type system, the module system with good visibility options, and macro system(s); it’s also a tendency to write code that doesn’t contain a huge amount of boilerplate but still allows local reasoning that helps.

To help people write maintainable Rust code we should consolidate resources² around

idiomatic Rust (like this collection of patterns and the API guidelines),
experience reports from the teams that have huge Rust codebases already (rustc and Servo come to mind but I’m sure there are many others),
and create new documentation around software architecture in Rust.

Use strike teams to promptly tackle new issues.

As mentioned above, there were some changes to how the official Rust teams work in 2017, and I think we should continue improving on this. To avoid becoming a slow-moving bureaucracy that is not able to react to new challenges, I’d like to see liberal usage of ‘strike teams’. I.e., find a group of people interesting in working on one concrete issue, and then work on that issue to as quickly as possible be able to disband the team again.

At the end of 2017 this implicitly happened a bit around adding WASM support in Rust and developing stuff with it, which allowed us to get some very impressive projects on the road.

Strike teams also allow different kinds of people to find something they are interested in. While there are some folks who are very proud perfectionists that really smashing the last remaining bugs and stabilizing a feature, other are more interested in hacking on shiny new things and pushing the ecosystem forward with bold experiments.

Conclusion

I’m very much looking forward to the roadmap proposal and all that we can achieve in 2018!

Here are some other #Rust2018 posts³ if you want to keep reading:

cough Did I mention I’m a freelancer with lots of Rust experience? cough ↩
This has also been called “intermediate level documentation”. If this seems fuzzy to you, and my above list doesn’t look as metaphorically exciting as it could be, have a look at one of these tweets. ↩
I only linked the username because they basically are all title “Rust 2018” :P ↩