Technically speaking, it’s past the deadline for #rust2020 posts, but I’m running late this year, and I’m going to post something anyway. In this post, I am focusing on what I see as the “largest scale” issues, and not on technical initiatives. If I have time, I will try to post a follow-up talking about some of the key technical initiatives that I think we should focus on as well.

TL;DR

We should do an edition, and we should plan for it now

The time is ripe to talk about encouraging investment from companies

A foundation is perhaps part of the solution, but not the whole solution; we should encourage active participation from stakeholders

Organizational improvements can also encourage investment

Organizationally, we’ve done a lot in 2019, and we can do more in 2020

We should think on longer timescales

One of the questions we asked this year was whether we should plan for a Rust 2021 edition. I feel pretty strongly that the answer is yes. There are a few reasons for this.

I think one of the biggest parts for me is that I think it is very healthy for us to be planning on a 3-year timescale. The fact is that many of our projects these days take years to bring to completion. It is good for us to talk about roadmaps, but it is also good for us to look to a slightly longer horizon.

I don’t necessarily think this kind of “long range” planning should be about specific goals and features, but more about areas of focus. Moreover, I think we should be careful to control our ambitions – I think for example that, in thinking about 2019, we outlined a number of features that are far more realistic on a multi-year timescale.

Plan for edition changes early

Editions also, of course, give us the option to make changes we couldn’t otherwise make. For those who aren’t familiar, editions let us make “backwards incompatible” changes to Rust – but in a way that keeps old code working. These changes might be something as small as adding a keyword, or as large as the module reform we made in Rust 2018. The beauty of editions is that, since they are opt-in at a crate granularity, we are able to keep supporting older crates seamlessly. This means we can improve the language gradually without forcing the entire ecosystem to upgrade in a coordinated fashion.

In Rust 2018, we made a number of these sorts of “migrations”:

We modified use statements to introduce the use crate::foo notation

statements to introduce the notation We transitioned to the dyn Trait syntax

syntax We introduced a few keywords

Crucially, we also provided tooling to automate these migrations. This is what made changes like the first change possible at all, since that change affected almost every crate ever written.

I don’t expect us to do anything as dramatic as changing use statements in Rust 2021, but I am confident we are going to want to make a few backwards incompatible changes. I don’t know exactly what they will be yet, but I do know that now is the time to start planning them – we want to be front-loading that kind of work so that we can have time to work on the documentation, migration tooling, and other things that we will need.

Yosh’s #rust2020 post covered this topic quite well, I think. In the timeline section, he breaks down the time available, concluding with:

All together that leaves us with about 12 months total to plan and prepare the next edition release, starting January 2020. This should be enough time to successfully plan and draft a new edition, with some slack to work with.

We are seeing increased investment from many companies

2019 marked a real turning point when it comes to companies using and supporting Rust. I remember the time when everybody I met who used Rust was a hobbyist. Then we started to see startups and smaller companies experimenting with Rust, looking for a way to boost their productivity when writing low-level systems code. And now we have major companies like Microsoft, Amazon, Facebook, and Google adopting Rust for major projects. Somewhat unexpectedly, to me anyway, Rust has become the language of choice for a lot of Blockchain companies.

This increasing adoption has also begun to translate to increased investment in Rust itself. Microsoft and Amazon, for example, are now sponsoring the majority of Rust’s CI costs. A big part of the async-await development was done by developers on Google’s Fuschia team. And so forth.

But we need more people paid to work on Rust

Nonetheless, for Rust to really thrive, we need to see more people paid for their work on Rust teams. As Erin put it in her #rust2020 post,

When 1.0 launched there was ~30 members of The Rust Programming Language, now in 2019 we have ~200 members. This is nearly 7x the amount of members, yet we’ve changed very little to be able to adapt to this growth. No where is this more evident than out of the now 200 or so members, the number that are paid for their time on Rust is still in the single digits, and this doesn’t look to change any time soon.

One thing I’ve observed time and time again is that bigger, complex projects really require dedicated leadership and organization – and this often takes vast amount of time. I talked some about this in my post on “More than coders”. The plain fact is that this kind of time is often unavailable on a volunteer basis.

Shifting the focus from adoption to investment

In year’s past, when we thought about companies and Rust, a big part of the focus was on encouraging adoption. But I think at this point it’s time for us to start encouraging investment. There are a lot of companies using Rust now, and the time is ripe to ask ourselves how we can help those companies to help Rust.

But when we ask those questions, I want us to be careful in our thinking. I don’t think there’s a single, simple answer for how to increase investment in Rust. In fact, I don’t even think there’s a single answer to what investment is. I would love, of course, to see more people hired to work 100% on Rust. But there are so many other ways to invest in Rust:

Sponsoring Rust conferences, meetups, or other social events

Sponsoring employees to attend the Rust All Hands

Encouraging employees to spend work time working on Rust as a sort of “20% project”

Building ecosystem libraries that everyone can use

Sponsoring Rust’s CI or other infrastructure

Sponsoring the Rust All Hands, Increasing Rust’s Reach, or other Rust org initiatives direectly

Using contracting or grants to support the maintainers of the Rust project or key figures in the Rust ecosystem

Many are stronger than one

Even though Rust was started by Mozilla, Mozilla never wanted to “own” Rust. We’ve always wanted Rust to have its own identity and to be supported by many companies and groups, big and small. Fundamentally, this is because having many stakeholders makes for a better, more robust language. Part of what accounts for Rust’s success is that we’ve attracted a diverse set of contributors, who were able to push us to improve the design in any number of ways.

I mention this because, as we talk about money, I think we will also need to address the question of whether to form a Rust foundation. I am increasingly thinking that this is a good idea. I think that having a central legal entity that represents Rust could solve some challenges for us, for example, and I also think having a central bank account could help for “group funding” of infrastructure, events like the Rust All Hands, or programs likes Increasing Rust’s Reach. But I don’t expect this Rust foundation to directly “solve the problem” of paying people to work on Rust, nor do I think it should. I would expect it rather to be one piece of a larger puzzle.

Whatever we wind up with, I think it’s important to encourage companies that use Rust to employ key figures that actively participate in the Rust organization (whether that be full- or part-time). We don’t want a setup where the Rust organization is the foundation, supported financially by others. We want a setup where the Rust organization is directly composed, as much as possible, of its users and stakeholders, all working together.

Improving our organization can lead to increased investment

I think a lot of the changes we need may be more organizational than specifically to do with money. For example, I enjoyed reading Parity’s #rust2020 post, and I was particularly struck by this paragraph (emphasis mine):

For many of the issues raised above, we are also happy to jump in and help out–and on other issues as well. We are a Rust company after all—we believe in the language, its ecosystem and the community, and want to be a valuable participant in it. … However, it’s often unclear whether the work is worthwhile. To a business, it is hard to argue that one might spend a month or two working on a new feature without any assurance that the approach taken would be accepted.

This is something that’s been on my mind quite a bit lately as well. If you are a company or organization that would like to help make changes to Rust, how do you go about it? I’ve been getting this question more and more lately as I go and talk to companies. Sometimes, the question pertains to a single feature, like custom test frameworks, or custom allocators. Other times, the question is about a broader initiative – think of the Sealed Rust pitch that Ferrous Systems posted some time back.

In principle, the RFC process is supposed to help serve these needs, but I don’t think in practice it’s working very well. I think though that we can tweak and improve our system to overcome some of those shortcomings. What’s more, if we do, I think that same system won’t be specific to companies. After all, if you’re a volunteer contributor interested in pushing on a specific feature, you face the same the problem. (This, for example, is precisely the problem that shepherding is taking aim at.)

2019 saw a lot of progress in organizational matters

Organizationally, I’m quite proud of all the work that we did during 2019, even though I still think we’ve got a lot of room to go. Just looking at the compiler team, for example, we really refined the concept of working groups, we clarified the concept of compiler team contributors, and we introduced other innovations like the weekly design meetings. These meetings have meant not only that we just have a lot more communication as a team, they’re also great for people looking to eavesdrop and learn more about how the compiler works. The lang team is publishing its minutes and (frequently) recordings of our meetings, which are also open for anyone to attend; the core team is also publishing recordings on a best effort basis. The intrastructure team has made great strides in documenting their procedures on forge, as have other teams. At the project level, we introduced the leadership sync meeting, the Inside Rust blog, and we’ve been trying to get a governance-focused WG off the ground.

We can do even more in 2020

Over the next year, I’d like to see more progress on how the project operates. Some of the goals I think we should be working towards:

active mentorship to help leads formulate roadmaps and plans, as was discussed in the recent compiler-team retrospective

documenting all of our governance procedures and other details on forge

more transparency about our priorities, and a clearer process for requesting that something be made into a priority

improving followthrough and avoiding unbounded queues; when we start designing a feature, we should see that effort through to the end before we pick up new things

extending our governance to cover “cross-cutting projects”, which draw on the expertise from many teams; right now, for example, the “handoff” between the lang team doing the design for a feature and the compile team starting to implement is informal and often just fails to happen

Conclusion

As I wrote in the beginning, I’ve not tried to address technical initiatives in this post. I have thoughts on those too, and I think I will try to do some follow-ups there. In summary, for Rust 2020, I believe: