A while back the Rust team did their annual call for blog posts asking for perspective on what the community thinks the next year in Rust should look like. Here are my thoughts (albeit a bit late).
Process and Governance
The most important issues for the Rust community to face in 2020 are process and governance. At the end of the day I think governance and process go hand in hand, so I’ll discuss the issues related to them together.
Burnout
As mentioned by Yosh in his Rust 2020 blog post, there are definitely many people who have burnt out or on the verge of burning out inside the Rust team. I typically view burn out as a failure of process, and I don’t think the burnout phenomenon in the Rust community is any different. There have already been some suggestions on how to fix this including a discussion of tweaking the RFC process to make it easier to manage. A lot of the overwhelming feeling of participating in Rust development can stem from such processes where a small collection of people are confronted with the opinions of hundreds of others. When even one of those people don’t take the time to understand the context up to that point or downright fail to act in good faith, this can quickly take its toll.
Rust benefits greatly from its open development, but that doesn’t mean that this process is perfect. My hope in 2020 is that we as the Rust community take even more time to think through these issues and try out proposed solutions. While I definitely believe that Rust represents more than just a programming language compiler, it’s definitely not worth the mental health of those who put the most into it. They deserve better.
Ownership
Those involved in the Rust project have an understanding that no one entity “owns” the Rust project. Despite Mozilla employing a decent amount of those that are paid to work on Rust full time, there is an implicit understanding that Mozilla wants Rust to prosper outside of being controlled by just one company.
While this has worked until now, the involvement of many other companies in Rust means that it will become more important for this informal understanding to become formalized.
While this may not seem like an extremely urgent issue, I do believe that as part of Rust becoming a language that’s used widely in industry, we should tackle these issues before they actually turn into problems. What form this actually takes, I’m not sure, but it’s time to start talking about it openly.
Managing Change
The Rust team and community should be proud of the level of backwards compatibility the language has been able to maintain despite such a quick release cycle, but I believe it’s time to take this to the next level. While it’s safe to say that the language provides good stability guarantees, when one looks at the details, things get a bit shakier. Locking down more guarantees that surround the language and tooling will become more important the more that private software (which cannot - yet - be tested by crater) gets written.
Some of this is already being worked on, including Josh Triplett’s RFC on more formalizing the target tier system which will offer a bit more of a formalized understanding of how targets move up and down the tier system.
Some processes though remain under specified. For example, it is up the language team to make decisions on what constitutes a breaking change. Often times, the language is tweaked in such a way that could theoretically break existing code. Crater runs are often used to determine how much code this change actually breaks, but as more Rust code begins to be written off of GitHub public repositories, the less Crater runs can actually tell us if a technically breaking change constitutes an actually breaking change. Leaving this decision ultimately to the discretion of the language team doesn’t seem like a bad idea per-say, but not giving the language team a more formalized framework for making such decisions seems like we’re only asking for inconsistencies.
The Language and Compiler
Rust as a language is really coming together not only in terms of features but also in terms of developer experience. There’s not really any large features that I’d want to add to the language with the exception of const generics.
Work to make the compiler faster and to make it a “first class compiler for IDEs” is definitely something I think should be a priority. Beyond this, the work that ekruber is doing with regards to compiler messages is some of the most important work in Rust right now. I hope even more people can get involved!
Beyond this, I’d like to see small well thought out features that expand Rusts capabilities in terms of work loads that it can be used for. I recently posted a pre-RFC on safe-transmute which would allow Rust to safely do something that’s fairly common in low-level usages of C. This along with other pre-RFCs like inline assembly should be relatively self-contained meaning that they make the language more capable without making it more complex for those that don’t need such functionality. More features like this should be priority.
Conclusion
These are exciting times for the Rust community. Rust certainly feels like it’s hit an inflection point where it’s starting to see real usage in industry. This requires us as a community to take a step back and examine our processes and governance structures to make sure that we point the Rust project in a direction we’re all happy with.
Here’s to 2020 being the best year for Rust yet!