this post was submitted on 27 Jul 2022
11 points (92.3% liked)

Rust Programming

8011 readers
1 users here now

founded 5 years ago
MODERATORS
top 3 comments
sorted by: hot top controversial new old
[–] Ephera@lemmy.ml 5 points 2 years ago (1 children)

Interesting. The whole async-await stuff has always been a bit risky to me (in any language), because yeah, as soon as you start introducing it, it spreads through your code base limitlessly.
This effort won't yet quite fix that, but it will at least stop it from spreading under certain circumstances.

I often like to use the actor pattern, which gives you relatively nice asynchronous code without language-level support, and well, that too spreads over your code base, but it spreads differently.
It requires core components to be turned into actors and communication between them needs to be done with messages instead of method calls, but on the plus side, within those actors, you write synchronous code, so utility functions and such don't need to know about this async-vs-sync problem.

So far, it always felt like this was just the better solution, if you were willing to pull through with the whole message-based communication. But yeah, I'm curious to see what the Rust team comes up with. If they can 'fix' async-await enough, maybe that's worth another look.

[–] jokeyrhyme@lemmy.ml 3 points 2 years ago

Yeah, async/await in Rust is still one of those areas of least-comfort for me (especially since there's enough runtime-specific code that it dictates the rest of your library choices)

[–] northbound_goat@szmer.info 2 points 2 years ago

The "sandwich problem" looks like just a lack of a traverse function to me.