Rust 2023 (by Yosh)
— 2022-12-21

  1. async
  2. ambition
  3. cohesion
  4. automation
  5. conclusion

Previous posts1: 2018, 2019, 2020, 2021

1

I didn't write a "Rust 2022" post, sorry.

The core team used to put out a yearly call for blog posts. My colleage Nick published their "Rust in 2023" post last week, and encouraged others to do the same. I like the idea of taking a moment to reflect on larger topics, and so well, why not write a post!

I want to do this a bit differently from the usual formula though. Rather than writing something with the specific intent to build some sort of "Rust 2023 roadmap", I want to instead take this as an opportunity to reflect on the state, values, and priorities of the Rust project. More of a snapshot of my current perspectives, than a concrete list of action items I think should be tackled. Here goes!

Async

Probably most of my work will continue to focus on async Rust. A majority of programming jobs are either frontend or backend related 2, and async is important to both. Anecdotally I know that async has been a major driver for the adoption of Rust - and the more we can improve async Rust, likely the better we'll do in those fields.

2

The 2022 stackoverflow survey notes 26% of people work on front-end, and 43% of people do backend work. These numbers are non-exclusive, since folks could be doing both (src) - but I think it's fair to categorize this as a majority of jobs.

Work has been progressing a lot here. Diagnostics have become significantly better. We now have IntoFuture stabilized. And both safe stack-pinning and async fns in traits are on the horizon. And slightly further out is the work on async iteration, async drop, async main, and keyword generics.

I should probably get around to writing the end-of-year update post for the Async WG I promised I would write. But the tldr is that async Rust is important to Rust's future, we've made a lot of progress over the past year - and I think we're in a pretty good spot to keep making progress.

Ambition

It's winter holidays, and I'm not going to ping people to clear quotes. But someone I respect a lot once remarked: "Rust does best when we're ambitious" - and I agree strongly with this. I think the work we're doing on Rust is far from done. Rust is in a spot where people can be productive, but there are still so many limitations. And when people run into this, I want us to do better than: "Well, that's just the way things are". We can in fact have nice things!

As a general attitude, I want us to stay ambitious. To imagine a world in which better things are in fact possible. And then doing the work to get there. Rust combines the desire for a radically better programming language with the motivation to actually get things in people's hands. And I think our work is some ways only just getting started 3.

3

It's hard to say how long programming languages are expected to last, but we're seeing Rust adopted in some pretty high-stakes places which are likely to stay around for a very long time. This means it's possible Rust will outlast us, meaning that in retrospect now might very well still be "the early days" in terms of Rust adoption. We won't know for sure until we're there, but imo this is not an unlikely outcome of our current trajectory.

4

I feel like everyone attributes this quote to someone else at this point, but: the design space of a programming language is fractal! There are infinite details to dig into, and there's also a real art in deciding what to prioritize.

Cohesion

"What is Rust" is one of those fun open-ended questions which doesn't have a right answer. After all: Rust is a programming language. Or maybe Rust is a feeling in our hearts? I think Rust is the friends we make along the way. Really, it's us who get to decide what Rust means to us.

Pragmatically, I think Rust is not just a programming language. Cargo is Rust. Rustup is Rust. Crates.io is Rust. All the tools, guides, websites, people, and programs together make "Rust". And I think that with that come some interesting questions about governance, power, and cohesion as well.

I won't bore you with some long essay on the reflection of power dynamics within open source ecosystems. But what I will say is that Rust has done remarkably well in ensuring people using the language are presented with a relatively cohesive experience! The compiler, formatter, versioning tool, guide, package manager, and standard library are all owned and operated by the Rust project. And I think this is a strength we should continue to build on.

I'm really happy that we've recently seen the addition of the cargo add command, removing the need to rely on the external (yet trusted) cargo-edit crate. And if I'm not mistaken work on cargo-semver-checks is currently ongoing with the intent to integrate it into mainline cargo as well. 5

5

Somewhat proudly one of my own contributions along these lines in the past year has been to bring the core functionality of the num_cpus crate into the stdlib. One less crate to learn about!

I believe that one of the main strengths of Rust is that we're creating something together which looks and feels cohesive. I think it's good to keep adding features as long they end up feeling part of a whole. And I think this is something that's worth reflecting on, and identifying potential places where we may be able to lean further into this.

Automation

I sometimes think about the 80/20 rule: "80% of work takes 20% of time; the remaining 20% in 80% of time." I'm not sure if this has a proper name, but there's also what I like to call the 100% rule: "Once you've solved 100% of a problem, you can stop thinking about it completely".

Take for example memory safety in systems programming languages. Using fuzzers and sanitizers you may be able to easily address 80% of bugs. But the remaining 20% of bugs will take some effort to find. And even when you do; code changes over time, which means that you'll be unlikely to ever afford to stop looking for these types of bugs.

Compare that with the borrow checker, which guarantees there will never be any memory safety bugs: meaning you can catagorically eliminate the concern alltogether. The 80/20 rule is often used to indicate that "80% of effort is good enough". But I think it's important to realize that sometimes achieving 100% of a solution can provide a value-add which far outweighs all incremental steps that come before it.

I want us to keep looking for ways in which we can structurally eliminate issues through automation, so we can stop thinking about them alltogether. Taking cargo-semver-checks as an example again: rather than needing to learn and check for things like "variance" and "contravariance". When publishing new versions of crates, we should just have a tool which checks it for us - and patiently explains how we can fix the issues, even if we're not completely sure about what the underlying rules are.

I think it was Ralf Jung who once said something along the lines of: "The job of an expert is to learn everything about a field there is to learn, and then distill it so that others don't have to." 6. And in my opinion building tools is one of the best ways we have to propagate domain expertise. I think this is something which we should keep leaning into 7.

6

This was definitely a TWIR quote of the week at some point. I think late 2020/early 2021 ish? If someone remembers the link I'll update this post!

7

I believe programming language features such as the borrow checker, or capabilities fall under this as well. Rather than memorizing and manually validating a set of rules, we can/should use automation (a compiler) to automate this reasoning for us. Because for example even interpreted languages are not free from having to reason about lifetimes and ownership; the only difference is that the language doesn't provide facilities to automate this reasoning. So people instead have to rely on techniques such as defensive copying to prevent aliasing bugs from occurring. (This could probably be a post on its own, so I'll just stop here hah.)

Conclusion

I can probably keep talking about Rust at length; that's what this blog is for after all. But I think these are some of the key points I wanted to hit. Before closing out though, I probably should briefly cover my thoughts on governance:

To close out: I think we're doing great, and I'm excited for the direction we're headed. Happy 2023!