Here are some quick thoughts on priorities for Rust 2019. Perhaps the thoughts are a little scattered, and some not fully-formed. But I wanted to get the gist of these ideas out there before I get derailed on some other project.

I have many technical wishes for Rust, the language, in 2019. However, I’m not going to mention any in particular in this post. In fact, I can almost say that I’d prefer for there to not be a focus on achieving technical milestones in the next year.

(this is not a repudiation of those who ask for features. I know that getting community feedback on prioritizing features is important, but it does have a way of focusing attention on what the language can/should do for us, instead of how the language as a whole can grow).

My thoughts are inspired by a post by withoutboats for Rust 2019. In it, he called for tacking organizational debt which had accumulated as the Rust team strove to make the language technically accomplished, but also accessible and popular.

I believe not only that the processes and institutions of Rust need to be shored up, but that special attention should be paid to people. Ultimately, people are what drives the language forward, whether it be through design, implementation, or outreach. If no people want to work on Rust, or are blocked from working on Rust, the language will stagnate. So when withoutboats points out that Rust the organization is struggling, perhaps it should be a call to action to address the most fundamental aspect of growing Rust: not features, but people.

This is not to say that there should not be any movement on improving features or process. Just that their effects and costs should be measured in people, as well as in technology.

When I say that effects and costs should be measured in people, I do not mean just allocation of time by core team members. Rather, that a person only has so much energy for so many responsibilities before they burn out. Sure, even if there is enough time to design a feature, lead a working group to implement that feature, delegate, write code, and engage with the community, does that mean that one person should? I feel tired just reading that list.

(and, as some have mentioned, there may not even be time).

A quick anecdote about the need for healthy leadership: I was the director of the 2016 US Go Congress in Boston. In the US Go world, it is well known that the burden of hosting the Congress can burn out the director, and the local community as well. While I made it through the Congress, and helped to run one of the more forward-thinking programs in years, it was a solid half-year before I had any desire to play Go again, and another year after that before I rejoined the community. Even now, I participate at a much reduced rate than before Congress. I have yet to attend another Congress. So I hope that nobody on the Rust team is so pressured and stressed that they would need to leave the community.

Finally, I’ll address the title of this post. Rust, please go slow. You are already an excellent language. While there are rough edges, you can compete with the best in a number of domains, and are ready to breakthrough in several others. Yes, certain new features (async/await, const generics, GAT) would surely please many software developers; we can also surviving without them. Rust developers are resourceful, we can hold down the fort until features arrive.

Rust is running a marathon, not a sprint. Please go at a pace fit for the growing the language, its organization, its community, its people, for the long haul. I want to be programming in Rust for a long, long time.