How to think about `async`/`await` in Rust - Cliffle
cliffle.com

HN discussion with some salient points. As to the post itself:

CAUTION: There’s a proposal to make code generic on whether or not it’s being used async, so that the same code could produce both a simple function and a Future. In this case you’d have to make sure to think about correctness in all possible ways your code could be used. I am suspicious, and I hope after reading this section, you are too.

I was suspicious before, but couldn’t put in words why. Now I know. :-/

  • almindor@lemmyrs.orgEnglish
    2·
    1 year ago

    async is broken. Some basic examples:

    1. a "something 3 levels deep in your dependency tree is not Send error when trying to do something like tokio::spawn for <reasons>
    2. tokio is quite bloaty, but also consider hiding sync behind async such as postgres (which started as pure sync crate) now just doing a block_on behind the scenes and forcing tokio on people that don’t even want async
    3. combining IO wait tasks with CPU busy-wait tasks can be quite tricky. tokio::task::spawn_blocking works but you are forced to do it at the lowest granularity level
    4. closures vs async vs async closures, nuff said
    5. async traits vs sync traits
    6. sync vs async code duplication

    I could go on. Just like some commenters on the HN thread, I think removing async and forcing nice library abstractions on top of epoll/kqueue/io_uring would be a better way to go about this.

    I’ve been there when C10k became a thing, I coded a Free Pascal networking non-blocking library lNet and added epoll and kqueue support to free pascal for that purpose. I understand non-blocking and IO wait issues, and I think async is wrong.