The Rust project is asking for blog posts about what the community would like to see happen with Rust in 2019. I originally wanted to write this post before Christmas, but instead I took some time off to meditate on what exactly I wanted to write (mostly by laying in bed, sick).

In the meantime, a lot of people have written their Rust 2019 posts. For example, I really liked fitzgen’s post, “Think Bigger”, because it looked at a few common areas from a new perspective. Very interestingly, many people have also written about how we need to tackle organizational issues and should not pursue/focus on technical features this year (cf. boat’s post and mgattozzi’s post).

I already tweeted a short teaser on what I had in mind for the roadmap, which I want to expand on in this post.

Unlock the next levels for Rust

Thinking about Rust’s evolution like a video game (heh), we have just reached level 2018. Our programming language is in a good state but there are a lot of progress bars for features where we need to get a few more experience points to unlock a new ability. (But let’s not stretch that metaphor too far.)

The first part of my tweet was:

Rust 2019: Get experimenting on the next big things.

What I want to set as goal is: At the end of the 2019, we should be at a point where we have a list of new things we want to be working on. “New stuff” is stuff we may have only considered in passing so far, but where no implementation exists today. But also, things we do not even consider “something that is great in Rust” today.

What

This is super abstract! In fact, can you quickly say what concrete things you thought of when you read “new things” above?

Did you think about the emergence of an idiomatic GUI library? Did you think about new working groups? Did you think about having const generics? Did you think about RFC process version 2? Did you think about having a having super fast debug builds? Those are all valid!

That is pretty much the point of this post: It might feel like with the release of Rust 2018 we have reached a solid point in the evolution of the ecosystem. But to me it feels more like we are on a plateau in front of the next ascent towards the mountain top. (See below for a mathematically precise illustration of that metaphor.)

And that is what I mean with “unlocking the next level”: We should spend 2019 trying to do our best to solidify our bases, get an understanding what is possible, and then look ahead and try to realize these possibilities.

How

How can we get there? My tweet contained a multitude of short phrases that you may read as suggestions:

Finish features. Streamline processes. Unblock new feature development. Go for experiments with high dividends, allow failures. Get an idea what Rust 2021 might be about.

For every roadblock we clear, people will be able to do new things, go further. And eventually discover new roadblocks, of course.

One approach is to collect feedback from current users, look at the issues they have, and try to fix them. When these issues are resolved, let people use the new version, collect their feedback again and repeat the whole thing.

Another idea is to shorten the feedback cycle by only prototyping the fixes, and immediately try and have people use and test it, to figure out what they want then. This works quite well when starting with a new project, but typically gets more and more difficult when you have an already established basis.

Who

This is not a black and white picture of course. People already have experiments going on in all kinds of areas.

A super precious resource in large projects is the time, space, and acceptance to do experiments. I have seen how time and time again truly magical progress was made in mere hours or days, when the right people got together at the right point in time and had the chance to sit down and work on an issue1. This tends to only works for a few scenarios, however. Getting an initial proof of concept going, brainstorming around conceptional roadblocks, for example.

The communication around Rust in 2018 was about “getting things over the finish line” however.

I have a feeling that the people who like to work on open source projects with the goal to “ship features” are often not the same people who want to do open source to experiment and try out new things. Which makes total sense to me: The reward for former is being part of an official product release2 while the latter allows one to play around with cool ideas (hopefully in the company of clever people one can learn from).

So, let’s try keep in mind that there are different stages in projects, and that different people want to participate in different capacities. While switching to a “feature freeze and stabilize” year might give us the chance to have an easier time with planning ahead and organizing what the teams will focus on, we might also lose and important segment of contributors. Additionally, we might not lose these people but in fact might see them skip over the whole structure we build and work on what interests them regardless of our plans.

Right now, people have a desire to be recognized as part of official teams, and try to help out by founding their own working groups, for example. This is very valuable – yet super hard to manage and keep track of. See also Florian’s posts that resonated a lot with me (and that I just saw after writing this paragraph).

What again?

Sorry, this post drifted off towards a place where it was more about me reflecting about change itself but it doesn’t answer what we should do next week. Maybe I can save it by quickly writing down a list of cool, concrete things we could do? (This is heavily biased by my involvement in the dev tools team and personal interests, of course.)

  • Continue rust-analyzer with the goal of sharing code with rustc but also get to a point where it is easy to contribute to the next version of RLS
  • Enable projects to contain custom lints (that might actually re-use some of the then-external compiler libraries)
  • More powerful rustfix: Fix clippy lints, as well as deprecation warnings, and allow migrating to newer idioms but also new versions of libraries!
  • Improve rustdoc (cf. grey’s post)
  • Experiment with new approaches to getting data from the compiler (or even rust-analyzer) to enable people to write their own interfaces to discover APIs (be it “rustdoc2” or a thing that draws nested modules and types in VR)
  • Play with different approaches to managing an RFC process that works at Rust’s scale
  • A push for more work on custom test frameworks, to get to a usable and interesting state where the community can get more involved
  • Stabilize async/await and then go ahead and tackle generators, too
  • Look at how we would (re)write some APIs once we have associated type constructors
  • Experiment with alternative compiler backends – be it running everything in miri or using cranelift for debug builds

Conclusion

Rust 2019 plan

  1. I’m already super hyped for the Rust All Hands in Berlin in February! ↩

  2. Rust is seen as being notoriously difficult, so being able to say “I contributed to Rust 2018” has some weight to it on a CV. ↩