We are 10 months after the last call for blog posts and a lot happened since. I won’t go on the obvious 2020 stuff that happened and stayed focus on Rust matter. On a more personal level, I’ve published my first crate which brought a weird sentiment of accomplishment 😄 I’ve also change job again, leaving embedded domain to do more high level projects, but I’m still working with Rust so I’m quite happy (and lucky) about it.

However, my perspective has changed and so have my priorities regarding Rust.

Embedded

As I’ve left the world of embedded development, all my previous items regarding this domain are selfishly not on top of my list anymore, even if I think they’re still important in the long run to have a safe IoT. I keep an eye on the news on the domain, and I can see that (good) stuff is happening, so I’m not worried and I’m certain that one day, we’ll see some Rust API from chip makers.

async Error Messages

Since January I played a lot with async/await and I’ve cut myself on some rough edges while using with it.

I’m working on some (closed source) backend stuff using warp and oxide-auth. The thing is that oxide-auth didn’t support async at that time so my company decided to contribute to the crate in order to finish the async work which was started by the crate’s author, but dormant.

After adding necessary code to oxide-auth, it was time to port my app to be fully async and then it happened. A gigantic wall of errors pointing at a line that doesn’t make any sense to me.

The error was pointing at and_then from warp but it was because of trait bounds not satisfied in oxide-auth and it took me days figuring out where they were missing.

What I’ve learned is that async code is hard and I think the error messages involving futures could be better.

Deadlocks

Another aspect of concurrent programming is dealing with shared data. Using async/await makes concurrent code so easy to write that I totally missed some double lock while write my Discord rolling dice bot. But Rust doesn’t prevent deadlocks from occurring and it’s not something it claims either, as it’s not a matter of memory safety.

Nonetheless, I wish we have something to address that though. I think some tool to help us dealing with this kind of error would fit into the whole "empowering" people idea.

Usual Suspects

Otherwise, for this third participation to the blog call, we still have the usual suspects that I wish for:

• Compilation speed: benches show that we’re progressing, but I think that when it comes to speed, we never get enough of it, so let’s say it’s the last time I mention it 😉
• UI development: I’m still waiting for the messiah is this domain, but it is hard work and maybe someday soon, I’ll be empowered doing native UI by Rust.
• IDE support: this has seen a huge progress and my wish to replace RLS with rust-analyzer is becoming true as a RFC to do exactly that has been merged! But now that it’s on the way, ra must deliver a giga extra experience. A friend coming from Kotlin was really chocked by the weak IDE support we have. Yes, Rust has not the same level of complexity and that’s why, but none the less, we need to pursued the effort and I have no doubt that we’ll get there eventually!
• Error management: I though things were beginning to settled on this matter, but suddenly, here is a (great) talk on error management and yet another error management crate. I haven’t even looked at snafu that we have eyre now which seems great. I don’t know what to think about it, but it left me with a feeling of fatigue when it comes to "how should I manage my errors".

On "Point" Release

Maybe it’s me, but I have the feeling that lately, the need to release a 1.x.1 or even 1.x.2 happened more often because of undetected regressions. Each time the bug is not huge but I confess I felt annoyed about these.

Rust 2021

Rereading my post, I guess the theme for #Rust2021 would be "more stabilization on async", especially around async error messages which are clearly behind the other ones. Maybe some extra things to empowered people on the other hard part of concurrent programming that are the deadlocks.

Rust is in quite good shape comparing to its age and a lot of trust is being poured into it by a growing number of people and companies. I’m lucky enough to have a job where there is a wish to move away from C++ and I really hope that this oxidation spirit will spread on more and more companies!