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 :D 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.
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
oxide-auth. The thing
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
at a line that doesn’t make any sense to me.
The error was pointing at
warp but it was because of trait bounds not
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.
Another aspect of concurrent programming is dealing with shared data. Using
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.
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
rust-analyzeris becoming true as a RFC to do exactly that has been merged! But now that it’s on the way,
ramust 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
snafuthat we have
eyrenow 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.
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!