Rust in 2023
The core team used to call for blog posts to help plan the next year. The core team has pretty much disappeared and certainly hasn't called for blog posts, but I'm going to write one anyway because I have opinions and I want you to hear them. Sorry. I think you should write such a post too!
First off, thank you for Rust in 2022! Thank you to all the contributors, teams, Foundation, community, and users. It's been a busy year and none of this would have happened without a lot of people putting in a lot of effort, often as volunteers. So, thank you!
In September, I wrote a blog post on ten challenges for Rust and I think these are things that should be worked on in 2023 (and right now, and in 2024, probably). I could probably just stop here, but I have a few more opinions on what should be prioritised in 2023.
Two big things
First, and absolutely most importantly, we (the Rust project) need to sort out our governance and leadership issues. This blocks so much potential work and the longer it goes on, the more 'governance debt' the project accrues and the more problems will build up down the line. It is embarrassing that a year after the core team imploded there still isn't even a proposal for a new leadership team. (Shout out to those working on it, I know it's a hard problem because people.).
There is a ton more work in Rust governance that I think needs to be done, primarily updating the RFC process and revisiting the team and working group structure. But this is blocked on having a leadership team and completing the current changes.
Second, and somewhat blocked by the missing project leadership, I think we need to revisit the 'stability without stagnation' strategy. Avoiding stagnation is super-important and we must not stop innovating, but we also cannot grow the language without limit. Complexity and size of the language has a cost and it is at odds with Rust's mission of empowering people to write reliable and performant software (which, IMO requires making the language simpler, smaller, and easier to use). Just because we maintain backwards compatibility does not mean we achieve stability. I'm kind of terrified about the volume of new features being discussed or designed, more so that there doesn't seem to be a strategy for where the language is going (or at least a published one).
Anyway, I don't think we should stop innovating or just slow down, but I do think we need to find ways to innovate that go beyond the 'experiment -> nightly -> stable' pipeline. We need a framework so that innovation can happen outside the core community and without requiring all work to happen to the same language which users are relying on for stability and maturity.
One partial solution might be to start planning a 2.0 release. Don't run off screaming just yet, I know back-compat has been important to Rust's success and change is scary. BUT, changes that are being discussed will change the character of the language hugely, one breaking change per decade is not so bad, and I'm sure we can mitigate breakage with tooling to some extent. Furthermore, having a 2.0 fork where we can experiment on radical ideas, and possibly learn something and then throw them away, would be useful even if we never actually launch 2.0. I think a 2.0 project could be a good way to keep innovating, keep excitement amongst volunteers, and still keep the 1.0 branch relatively stable. Importantly, a 2.0 release would be an opportunity to remove features, rather than just keep adding them. I.e., if we don't have a 2.0 we are trapped into monotonic growth of the language (fine, I guess, 'almost monotonic' due to editions, but close enough).
Similarly, I think the time is right to start a compiler 'rewrite'. Yes, yes, rewrites are often bad, but the downside of a rewrite is that we slow down work on the current compiler, and I think at this point in Rust's maturity that is not a terrible thing. And if the project doesn't pan out, we should still learn something. The potential upside, on the other hand, is huge! It has been very difficult to implement incremental compilation, parallel compilation, etc. with the current architecture. Starting again would let us apply everything we learnt from the ground up, this would give us an opportunity to make a serious improvement to compile times, and make future development much easier. Combined with a language 2.0, we could drop a bunch of technical debt due to back-compat, and make changes to the language to favour faster compilation.
Some smaller (but still quite big) things
Cargo. Cargo (and crates.io) is a super important tool and on the critical path of a lot of important things (supply chain security, security in general, integration with other languages, integration with other build systems, build times, ...) but is horribly under-resourced and progress is almost impossible (to be clear, the current teams are not to blame here, they are doing a great job under bad conditions and its only due to this hard work that things haven't completely blown up). I think there is an opportunity to fix this: throw money at anyone on the Cargo and crates.io teams that will take it, intensively mentor potential new team members (if those folk don't exist, then persuade some of the big companies backing Rust to find a person each to work 1/4 time on Cargo), expand the teams quickly with these people (even if they only have partial knowledge of the code base, etc.), start to encourage contribution and new features again. Hopefully, once exciting things are happening and there is adequate review bandwidth, there will be a virtuous cycle of contribution and we'll get out of the current pit.
Async. Work on async programming is progressing nicely and I hope that things start coming together and producing tangible results in 2023. I'm kind of frustrated with my own slow progress here, and unfortunately most of the async WG are busy with many other things, but things are moving and I think 2023 will be an exciting year for async. It should remain a high priority for the project.
Unsafe programming. The Unsafe Code Guidelines WG and others have been doing great work in terms of defining Rust's memory model, and providing tools and guidelines for unsafe programming. I think pushing further in this are is super-important for Rust. Safety is the main selling point for Rust, and the more we can do to make unsafe programming safer and easier, the better.
Finish and polish. I'm begging the teams to focus more on finishing things and polishing off rough edges, rather than starting new things. There are so many unstable and partially implemented features, plus so many features with things missing which were long-planned. I think burning down this list will have a much larger impact on Rust users (and potential users) than any new feature being discussed.
Finally
Kind of a wildcard to finish off: I'm really excited to see how data analysis/numeric computing with Rust is going to go next year. This is an entirely community-led effort and there is some really exciting stuff happening (Polars in particular is very cool). I think it's a really good fit for Rust, it seems to be reaching an inflection point in terms of maturity, and I'm genuinely curious to see if it will take off and where it goes.
Wishing you all a happy 2023!