I first got into Rust because a professor suggested writing an OS kernel in it as an interesting exercise. As a systems programmer, I came to really appreciate Rust because of it's safety guarantees, having spent a lot of time with C and C++. I still primarily think of Rust as a "systems language", even though that not what I primarily use it for.
Over time, I found myself primarily using Rust for:
- hobby OS kernels
- hobby distributed systems
- CLI tools for use at work (this one kind of surprised me, but Rust is really good at it). For example, this jobserver is my daily workhorse.
- contributing to
rustcitself
Looking back, I came to Rust for its memory safety guarantees and novelty, but I ended up staying because it's so pleasant to use for things I need to do often (like building CLI tools and servers to aid my work). Looking forward, I would like to see a day when I can use Rust for my main work -- hacking on OS kernels.
I also think that Rust is at a critical time in it's history. The Rust organization needs to grow and adapt accordingly. People have been saying this for a while, but I think it's more true now than ever.
Ok, enough intro. Here's what I propose for Rust 2021.
I still don't really like the idea of having editions at regular intervals. But if we're going to have one in 2021, I propose we should completely change the messaging around it to emphasize a lack of major changes. I think many people have a gut reaction when they hear a "new edition is coming out". For me at least, I think of C++, where my knowledge of perfectly idiomatic C++11 is rapidly becoming obsolete.
I also think the Rust team needs to clearly communicate why we are having an edition in its messaging. Otherwise, I think we will create a lot of confusion among end users as to what an edition is, how it's different from the normal 6-week releases, and what version and edition of Rust they should use. If the point of a 2021 edition is merely to give a sense of "progress", then as a consumer of Rust, I feel this is anti-goal. End users don't want "progress"; they want stability and they want their existing knowledge/experience to remain relevant. If the point is to convey a sense of "progress" to the developers of Rust itself, the I think RustConf is a better mechanism than an edition release.
I think finishing existing initiatives should continue to be a focus. A ton of progress was made in 2020.
I especially think that resources should be poured onto long-term initiatives such as Chalk and Polonius. These projects are critical to get major features like GATs working, but they are very researchy and require more hard work.
I also really like the idea of using MVPs for projects, which was done with async/await and const generics.
This helps unlock important/common usecases without requiring full design for all cases.
Towards my particular interests, I've been thrilled by recent work on asm! and stabilizing alloc failure handling.
I'm hoping that 2021 can be the year I can finally build an OS kernel on stable Rust.
We're very close, but there's a bit more work to go.
There's already been some discussion among Linux kernel devs about in-tree Rust.
I've been feeling the burn on this recently, as I've been working from home on my laptop. I'm pretty impressed with the work that has been done already, but I feel that we have a long way to go. I know a lot of hard work has been going into this, so thanks to all who have work on this!
As someone who used to work on Rust in my spare time and even co-lead a WG, I'm concerned about the scalability of relying mostly on volunteers. (I do want to clarify that my experience co-leading WG-rustc-dev-guide was fantastic, and I enjoyed working with everyone in that WG!) I've helped lead other volunteer-based orgs too in the past. In my experience, volunteers-based orgs are awesome communities. However, they also have a significant and rather constraining limitation: they always play second-fiddle to people's normal jobs and other committments (as they should).
In practice, this means:
- That the bus factor is much higher because a critical expert might disappear for a while (or indefinitely).
- That people gravitate towards the "fun" work. Generally, things like writing documentation, leading/organizing manpower, summarizing meeting minutes, or other less interesting work all get done less. Then, you end up with a backlog of things that nobody really wants to do.
- That progress can be volatile because it depends on a bunch of people's non-Rust lives allowing them to work on Rust.
- That people don't have to do anything you ask them to and they don't have deadlines to do it.
In my humble opinion, Rust has reached a scale where volunteer work is not going to sustain the project for much longer. I especially think that leadership/organizational bandwidth is reaching its limits. Finding volunteers who can do this sort of work is hard because most people just want to write code or work on that thing. We need to start paying people to work on Rust, especially to do leadership/organizational sorts of work.
I think the Linux kernel is a good model. There are some key people working for the Linux Foundation, but there are also companies that hire people to work on Linux. I realize there are legal and political headaches associated with this, but IMHO we should bite the bullet and figure out how to do it. I don't think Rust can continue under the current model for another 3 years, and I think figuring this stuff out now would be best before we get into a pinch.