Rust in 2021: We’ve done a lot, more to be done

Funny thing. It soon will be 3 years as I code in Rust. More than 2.5 years I write code in Rust professionally. cargo is my best friend, and thinking in Rust become such more natural than thinking in any another language.

I remember the times when the Borrow Checker was not so friendly, when you could not simply match on the mutable reference, and also the introduction to the concurrency was done by solving the dining philosophers problem right in the beginning of The Book .

Rust made a great progress since then, and you know what? I currently don’t have much to complain about. I know that language is under thorough supervision of guys who really care about both language and its users. And the tradition to ask community how they feel about Rust only confirms this fact.

So, before talking about future of Rust, I want to say thank you for all the language contributors, past and existing. You are the greatest, guys, thank you for your work!

Now, to the list of things I wish to be implemented in 2021.

Finishing the unfinished

While there are a lot of new features appearing in Rust, there are quite a lot of work that was started but not finished yet. These features are marked as “unstable” for way too long, and it makes me wonder when I will finally be able to use them in my code.

Some of examples I personally missed at least a couple of times:

• Generic associated types . It’s a big one, but it also a really helpful one.
• Proc macro diagnostic . An ability to spawn diagnostics from procedural macros is hard to underestimate
• std::str::pattern::Pattern . This is a weird one. It’s open since (sic!) 2015. A bit of unstable code that exists within stable interfaces . Why does it matter? Well, currently it’s impossible to write a fully-compatible wrapper around any function that has Pattern as generic argument. I’ve been taken aback by this a couple of times, and it was one of the few “wut?” moments.
• Built-in benchmarking . It’s already been mentioned in one of the posts, and I agree with this point. While criterion is handy and great, I see no reason why we still don’t have similar functionality out of the box. Especially given the fact that it’s already implemented, but probably just not polished enough.
• Trait aliases . It’s quite annoying that sometimes I have to write code like T: MyTrait + Send + std::fmt::Debug without an ability to put this trait set under a meaningful name.

I could list more items here, but eventually it’ll become just a copy of The Unstable Book .

My point here is that it would be great if finishing the work started a while ago will become a priority alongside with development new features.

Async / await

Obviously, asynchronous programming has become a big topic. async / await syntax is great, and I understand that there is much more work to be done. I’ll name just a couple of things I personally consider very important on this matter.

• Async traits. async_trait crate has almost three millions installations already, and I use it in several my projects as well. However, it has an issue: every future returned is Boxed. I would like to avoid dynamic allocation associated with an each method call, and it seems that the only way to achieve it is the support from the language itself. There are crates already that utilize async traits in their public interfaces, and I think it just a matter of time when it will become a standard.

• AsyncFn magic trait. I write a lot of higher-order functions in my code, and as more of functions are becoming async, I found myself writing code that looks like a hack .

  Ideally, I would like it to be something like:

  async fn async_hof<T>(f: impl AsyncFn() -> T) -> T {
      f().await
  }
  

Compiler development

This is not related to the language in vitro, but rather the language as the development process and the community.

• Instructions for newbies. rust-analyzer project has a great helpful tag: E-has-instructions . What great about it is the fact that the issue with this tag has not only description of the problem, but also an approximate location of problem source and a hint on the right way to solve it. It makes the contributions to the rust-analyzer much more pleasant experience, and I believe that having something similar in rust lang repo may result in a boost of new contributions.

Aand.. That’s it

Honestly, I thought it would be a longer list, but it seems that I’m able to enjoy the things I have already.

I’m curious about what will happen the next year, but for sure all the changes are going to be good.

Good luck, everyone! In Rust We Trust!