What I wish for #Rust2021
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
withrust-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 haveeyre
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!