Rust 2021

This is my Rust 2021 post. I believe that Rust has shown that “bending the curve” is
both possible and fruitful in programming language design. We also have a strong set
of values as a community, enshrined both in the Code of Conduct and the example of
various high-profile rustaceans.

For 2021 I really couldn’t care less what features go into the next edition. Don’t
get me wrong, I want the next edition to be awesome, but I believe this is table
stakes by now. I want us to take on the harder problems.

More than any one thing, at it’s core Rust provides a lot of value to it’s users. Programs written in Rust are free of entire classes of bugs thanks to rustc having your back. The core idea of borrowing and lifetimes providing memory safety without a GC is so powerful that it will eventually become mainstream. After a point, all new programs will be written in a language that is memory safe, whether that safety is provided by a GC, or by Rust, or a language that copies Rust’s features. It may take 10, 20 or 50 years, but we will get there. As an end user, that makes me happy.

Since the success of Rust or a Rust clone/copycat is guaranteed on a long enough timescale, the question becomes - how can we accelerate that?

It is again the time of year when the Rust team is calling for blog post as input to the next annual roadmap. This is my contribution.

This is my response for this year’s call for blog posts. I am writing this as a language implementer, not as a language user. I also don’t try to prioritize the problems. The two things I’ll mention are the things that worry me most without reflecting on the overall state of the project. They are not necessary the most important things.

Let us start discussing the things for Call for Posts. This post mainly talks about orthogonality and discoverability.

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.

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.

I saw the call for blog posts in the 2021 rust roadmap, so I figured I’d throw in my 2 cents, since I’ve been working on a project recently that uses rust on the backend. As the title suggests, I’ve been finding myself spending too much time on error handling.

I want to preface this by saying I’m just using rust for hobby projects. If I were writing rust in production or for a larger project I probably wouldn’t care that error handling takes some work to get right, I’d be more willing to put in the time to learn more about the best practices. As it stands though, I just want to code the happy path and getting stuck on error-handling to get the compiler to accept what I’m writing can rob me of motivation.

Hello, it’s me! I’m a somewhat new contributor to Rust and I’m about three blog posts behind. Here they are all at once:

* I work on docs.rs!
* I wrote a C compiler in Rust
* I spend way too much time working on intra-doc links
* I help make it easier to contribute to the Rust compiler

Wait, we’re writing a blog post here.

In particular I want to talk about that last point. I spend way too much time on Discord and I commonly run into questions like this:

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.

The core team is beginning to think about the 2021 Roadmap, and we want to hear from the community. We’re going to be running two parallel efforts over the next several weeks: the 2020 Rust Survey, to be announced next week, and a call for blog posts.