Aaron Turon     Archive     Feed

Rust in 2018: a people perspective

The call for #Rust2018 blog posts has generated a fantastic set of responses so far, and there’s already an emerging consensus around much of the technical focus for the year. Since I largely agree with what others have said on that front, I want to focus my post on the people side of things: what kind of impact do we want to make on people, both contributors and customers, in 2018?

Tell our story with a new product

Rust, like major web browsers, ships a new version every six weeks. There are a ton of advantages to this rapid release process, but two major people-related downsides:

  • Contributor downsides. Part of the appeal of rapid-release is that “there’s always another train on the way”; there’s no need to sprint to land something in a given release, because another one will follow soon. But that also makes it hard to “rally the troops”, bringing together the whole community to drive a cohesive set of goals all the way to completion.

  • Customer downsides. There’s a kind of “frog boil” effect from rapid releases; Rust is always improving, a little bit at a time, so it can be hard to fully grasp the large shifts that accumulate, especially if you’re not following development closely.

In 2017, we merged an RFC introducing epochs. While the discussion focused on the technical mechanics, to me the thrust of the idea is to supplement our release cycle with periodic “product” releases. These are sometimes called “marketing releases”, but I think marketing is just one (important!) part of the story:

  • When thinking about Rust as a product, we shift our focus away from the details of particular features, and instead think about the end-to-end experience of Rust. How do people hear about Rust, and what draws them in? What are their first impressions of Rust? What are the major wins and pain points at every point from novice to expert? This product focus helps us prioritize our efforts on what will make the biggest impact on people using, or thinking about using, Rust.

  • Part of the end-to-end experience is coherence: making sure that the set of features available on stable work well together, without major gaps; that these features are well documented; that the features are fully supported by tools like IDEs; that the compiler provides top-notch error messages for the full set of features; that there is likewise a coherent set of libraries available in the ecosystem that works well with the set of currently-stable features.

  • Aiming for a major product release gives us an opportunity, as a community, to come together and do something big that goes well beyond the usual six week cycle. We’ve seen this effect leading up to the Rust 1.0 release, and also with the more recent impl period. A product release gives us focus and drive.

  • Finally, there’s the marketing aspect, which comes in several layers. Releasing “Rust 2018” gives us a chance to say to the world that “Rust has taken a major step since 1.0; it’s time to take another look”. That, of course, ties directly back to the end-to-end experience; we’ll want to have a polished web site, installation process, etc. For existing Rust users who are not deeply involved in Rust’s development, the product release gives a way to understand Rust’s evolution as an overarching narrative. We can explain how the features stabilized since the previous epoch all fit together to establish new idioms.

I believe that 2018 should be an “epoch year”, in which we focus on shipping a quality product, for all of the above reasons. That’s going to require a lot of discipline, and a steady stream of stabilizations, but I think we’re up to the challenge!

Empower new technical leaders

I’m really proud of the work we did in 2017 to grow Rust’s formal teams, including creating several new subteams and expanding all of the existing ones. But we’re still suffering from a deficit of technical leadership. That’s in part because technical leadership is a hard job with mostly intangible effects; it’s largely about enabling other people to do the on-the-ground technical work, by working to reach consensus on constraints and high-level design. It requires enormous empathy, being able to understand the goals of a wide variety of people and thread the needle between them. And it often doesn’t involve landing reams of code with your avatar attached to them.

One of my personal lessons from 2017 is that we need to Think Big when it comes to Rust’s teams. Rust is a staggeringly large project with a huge and talented community, and we need its leadership structure to fully reflect that if we are to reach our full potential.

Concretely, this might look like:

  • Continuing to grow and subdivide the teams, so that we have more people in total involved in leadership and decision-making, but each individual has a narrower focus relative to today. This echos Niko’s points about impl period working groups, which was one such attempt. Splitting up the “tools” team into “dev tools”, “cargo”, and “infrastructure” in 2017 was another such example.

  • By the end of the year, having no single person leading more than one subteam. That would hopefully reflect a greater degree of importance and accountability around team leadership.

  • Improving the RFC process to make it more manageable for team members and the broader community alike. There are some strawman ideas on this front floating around, which will hopefully get written up soon.

In general, the point is that there’s potential for much greater parallelism within the Rust community than we have today, but to unlock that parallelism we need to grow our leadership capacity.

Engage corporations as users and sponsors

Rust’s adoption approach so far has been relatively “bottom up”: create a product with some strong potential business value, and focus largely on getting engineers “on the ground” to see that business value and work toward adopting it in their organization. Those engineers usually find small ways to use Rust, to prove it out in their organization, before getting more ambitious. It’s a great strategy.

However, as we seek to push further into larger, more conservative organizations, we need to supplement this bottom-up approach with a top-down one: make Rust appealing to CTOs. The primary way to do this is by making Rust look boring and safe as a technology choice. And we do that by showcasing our successes (we’ve commissioned some white papers to do this), being clear about where Rust makes sense and where it doesn’t, and projecting maturity, stability, and sustainability.

In 2018, we should take all of these efforts to the next level. We should have a polished web site that works for both engineers and CTOs, offering white papers and directing companies to sources of training, consulting, and support. And we should have a large and growing list of sponsors, like Mozilla, Bouyant, and Tilde and many others, who are funding Rust work in one way or another, either by paying their staff to contribute to Rust OSS, or by helping pay for project infrastructure, conferences, and the like.

Finally, we should do more to get production users engaged, at some level, in the RFC process. When we’ve talked to production users, the feeling is usually “we’re too busy writing Rust code and we trust you to get it right”. But the result is that RFC threads don’t present a picture fully inclusive of the production context.

Connect Rust’s global community

While we talk about “the Rust community”, the reality is that there are many Rust communities, separated by geography and by language. We need to do much more to connect these communities, again in terms of both contributors and customers. What are the important use-cases for Rust in India? What are the interests of volunteers in Brazil? What are the opportunities for Rust in China? How can we support each other, and communicate our respective values and needs?

Connecting these communities is not a small task, and I’m not sure what the right goal is for 2018. But I would love to see a greater awareness of and focus on this issue.

Serve intermediate Rustaceans

In 2017, we put a strong emphasis on early-stage productivity and learning curve, which has consistently been the top issue raised by the Rust survey. But last year, we’ve also heard an increasing plea for more “intermediate” level materials, focused on people who have learned the basic mechanics of the language and have written some code, but are looking for help on how to be effective as a Rust programmer. How should you organize a library? An app? When should you use traits? What about trait objects versus generics? And what libraries and tools should you be highly familiar with?

We’ve made some strides on this front in 2017 with efforts like the API guidelines and the cookbook. But there’s still a lot more to do in terms of (1) surfacing crates and tools that “every working Rustacean should know” and (2) fleshing out more guidance for how to wield Rust effectively, after you understand the features it provides.

Treat each other with empathy

One of the most amazing things about Rust is that it brings together grizzled C++ hackers, Raspberry Pi hobbyists, and JS pros and more into a single community. Rust offers something to all of us, despite that our goals, values, and interests sometimes diverge. Its ambition is to democratize robust, high performance code, to make systems programming better and more accessible to everyone.

The secret sauce has been a certain unwillingness to compromise: to find a way to take this diverse set of goals, backgrounds and contexts, and serve them all simultaneously by digging deep and thinking creatively. To keep that up, it’s vital that we don’t descend into tribalism or us-versus-them thinking, but instead to respect each other’s constraints, and trust that our constraints will be heard and respected as well.