Rust in 2021

It's that time of year again - time to think about a roadmap for next year! As I wrote last year, I think a good roadmap should provide focus for the project, but not specify how we should achieve the goals we choose. The rest of this post will be about what I think we should focus on and why.

People and community

As I've said a few times recently, we should focus primarily on our people and community. Ensure folk are not burning out and that the Rust project can be sustained into the future.

Diversity

As part of that focus, we should look at who "our people" are. I think in 2021 we must focus on improving the diversity of our community. We have tried to do this before, but honestly we need to try harder: it should be our top priority next year. Unless we give it that kind of commitment, we'll continue to 'do ok', but not make significant improvement.

I think that as a somewhat prominent tech project, we have an ethical responsibility to do this work. The state of the tech industry is an embarrassment in this area. If we only empower the privileged to be systems programmers or to contribute to our project, then we have failed, no matter how many memory bugs we prevent.

(Note that I'm focussing on 'diversity', not 'diversity and inclusion'. Inclusion is really important, and while we're not perfect, I think we are doing much better being inclusive than we are being diverse).

Foundation

Work is in progress here, but it is a huge undertaking and work will be ongoing. It has become somewhat urgent, but in any case I think having a Rust foundation is essential for the long-term viability of the project. It will be a long road to get there though, and next year we just have to get things off the ground (which is surprisingly complex, as things involving finances and lawyers often are).

2021 edition

There is still an open RFC, but I think it is very likely that we'll have a 2021 edition. This will require some work, but I hope we can avoid too much stress. We should continue our technical work as usual, if stuff lands in time it's in, if not, then we can wait till next time. In fact, really we should feature freeze at the end of this year, so there shouldn't be any new work for the edition in 2021. However, there will still be work to do to make sure everything works well together and to enable migration, etc. We should also focus on telling a good story for the release, so that we make the most of the opportunity to publicise the project.

Maintenance

Mature projects need more maintenance. Landing even small features causes big ripples across the project. Development is slower and we have a new kind of stagnation to avoid. As a project we need to evolve to focus more on maintenance work. At the moment we're still chasing new features and exciting changes for headlines, I think that needs to change. We need to keep people motivated and keep the project going and avoid interest dying off, even though we're not the most exciting thing on Hacker News.

Technical stuff

As far as new features or other goodies are concerned, I think less is more. We should focus on getting a few important things done (or make significant progress) rather than making incremental progress on a lot of things.

Async programming

Async programming is a huge deal for Rust. It works so well in many of the domains for which Rust is well-suited. We've come along way with async/await on stable, more and more futures things in the standard library, and so forth. However, it still feels like there is a lot to do.

On the language side, there are async functions in traits, async closures to stabilise, possibly some kind of syntax for iterating streams. Each of those seems to depend on a tower of difficult features. I'm sure there's more that I don't recall too.

There is a huge amount of library work to do too, moving features from the futures crate and into the standard library and stabilising it (or deciding not to move it, etc).

There is work too for tools - debugging and profiling would both benefit from specialisation for futures, and I think there is scope for more tools to help understanding async programs.

Then there is the education work - finishing the book, promoting async programming with Rust, writing documentation, etc.

Finally, I expect to see many new crates with an async focus - either fundamentals to help write async programs, or crates with a mostly async API.

Error handling

Error handling is one of the few areas of Rust which still feels experimental and incomplete. There has been lots of work in the past few years on libraries for error handling, and we should use that momentum to develop a standardised approach. I think that error handling is an area where there is an advantage in having a standard, ecosystem-wide solution because if all your upstream libraries use the same errors, that opens up opportunities for closer integration and better error handling.

Besides libraries, there are a few loose ends on the language side which could make handling errors much more ergonomic and natural. (Every time I'm forced to write return Ok(()); rather than return;, I want to murder something small and fluffy).

Rust Analyzer

I've been beating the drum on 'IDEs are important' for years now. Looking back I think we were a bit slow getting started here because early Rust developers (and users, including me) mostly came from C++ where there is not a strong culture of IDE use (except for Windows programming, but I think Visual Studio programmers are mostly a different community to open source C++ programmers). Starting to use Go for real programming earlier this year really brought home to me how useful IDEs can be, especially when learning a new language. Anyway, Rust IDE support is here, but not in the same league as other languages (e.g, Swift or Go, let alone more mature languages like Java).

Rust Analyzer (RA) is a chance to change that. It is already a great tool and it's getting better. It is IDE support designed from the ground up for IDEs. While that is a huge advantage, it is also a huge amount of work. We're essentially writing a second compiler with an entirely different architecture.

While RA is really good when it works (which is most of the time), it needs to mature as software - to be really useful in an IDE the quality bar is high. For example, to support refactoring, accuracy needs to be perfect otherwise compilation errors can be introduced. Due to Rust's type system and macros, that is difficult. Since RA must run embedded in an IDE like VSCode, stability is an issue too - it is essential (but difficult), to recover from any possible error.

Beyond IDEs, I think having a library or tool which has deep semantic understanding of Rust programs is a big win. It could be used to power all kinds of tools such as code search, refactoring, or automated error fixing. Again, accuracy here is really important.

Anyway, I think RA should be a big focus in 2021, not just for Matklad and other RA devs (who are already focussed on it :-) ), but for the whole community - more code contribution, testing, integration, and documentation would help, I'm sure.