The Rust core team has asked for the community to give their ideas on what they’d like to see from Rust in 2019 and give hints to what the next edition of Rust (tentatively Rust 2021) could be like. Here’s my take.
Stabilizing Rust
If you’re familiar with the history of Rust you might be confused with a call to stabilization. After all, Rust 2015 (a.k.a 1.0) was all about stabilization and the team has actually done a pretty good job with achieving this goal. So what gives?
While Rust 2015 defined stabilization around language backward compatibility, it’s time for the language, the tooling, the ecosystem and the governance to stabilize. Each of these characterize stability in a different way. Let me explain a bit more what I mean.
Stable Language
Stable as in unchanging
As many have already pointed out, Rust has reached a level of feature richness that makes it a productive language in most areas it intends to target. There are still a few major features close to landing that will round Rust out (e.g., async/await, futures, const generics), but with these finalized the language feels fairly complete. There will always be new features that undoubtedly feel incredibly important to some, but it’s hard to say that there is a language feature that is missing that would make the vast majority of Rust developers' lives materially better. Even still, with the large number of fundamental features that have come into the language over the past year, it’s hard to know what specifically could make Rust better without first stopping and letting the language age a bit in its current form.
Therefore it’s important that we collectively take a deep breath and wait before we add more features. Doubtless there are many who will read this and scream at their computers that their feature is important and should be included ASAP, but I believe the language deserves a break to be able to allow us to get to know it better in its current form before deciding what next to do with it. The core team has historically been pretty good at this, but I think it is now also up to the entire community to get better at saying “no” to features - if only temporarily.
Stable Tooling
Stable as in reliable
Tooling was a large part of the goal for Rust 2018 in an effort to increase productivity. While huge strides have been made (e.g., clippy and rustfmt reaching 1.0), there is still much work that needs to be done. If one gets lucky, tooling around editor and IDE support can “just work”, but many times it doesn’t. Getting tooling to the a point where a large majority of users view Rust’s tooling as best-in-industry is something the community should begin to set their eyes on.
Rust is in a position for this to be the case - with a robust type system, single compiler and dedicated build tooling and package management system, Rust can do a lot more than other languages without these advantages can.
Stable Ecosystem
Stable as in predictable
There has long been a call for stabilization of the ecosystem both in the form of having more crates reach at least 1.0 and also in the form of some way of specifying “blessed” crates that can be seen as “the standard way” of doing things even if they are not in the standard library (e.g. serde). While many crates have reached 1.0 there still is a lack of a good solution for a resource on “blessed” crates. Coming to a conclusion on this is imperative for stabilizing the ecosystem.
Additionally, we need the working groups to continue their work of fleshing out the foundational crates for their respective domains. The working groups also need to do a better job of working with the wider community to call on them for support with experimentation and stabilization of foundational crates. Beyond this, working groups should not be afraid to play favorites when its clear that a certain solution is gaining traction. For instance, I was surprised to learn that the Tokio team and the Networking Working Group communicated surprisingly little about shared goals.
Stable Governance
Stable as in foundational
Many have already commented on the need for a renewed look at how the Rust project governs itself. Aaron Turon’s Keynote at RustFest Rome and Boats' blog post on organization debt are both excellent takes on this. I’ll defer most of my views on the subject to them because I believe they both do a great job on laying out the issues.
One additional thing I’d like to see is more first class documentation on how to organize groups within the overall Rust community. Docs on how working groups are formed, run, and organized would go a long way. This would hopefully more easily allow an expanded range of working groups that can in turn help tackle the challenge of stabilizing the ecosystem.
Conclusion
Rust has come a long way since 1.0. In particular this year has been exciting for the ever increasing pace of companies announcing that they’re using Rust in production. 2019 should be a year where we double down on Rust as a reliable choice for production work with a stable language, tooling, ecosystem and community!