I wanted to figure out if async rust still sucks to use, and as of 2024 it was apparently still bad enough for people to assert that code like this isn't especially difficult to write:

(source: https://users.rust-lang.org/t/avoid-async-rust-at-all-costs-comments-from-experts/105860/16)

I like async/await in theory but in practice it is nearly always used as a justification for _HORRENDOUS_ designs. Something about it just causes insanity.

FWIW, async Rust from what I recall also has more fundamental issues, like "selecting on two channels in any of the major frameworks has the chance to drop a message on the floor if they both unblock at the same time."

What I remember discovering was that there were ad hoc special cases to prevent this in trivial cases but the general problem still existed.

@pyrex
Practically you'd write `tokio::task::spawn_blocking(|| { sync_code() }).await?` which has been added some time before November 2019 (the changelogs don't go that far)

(Specifically, what I remember is that a lot of operations were implemented as a general "schedule a callback that will pull a Thing from a channel and then complete a future," and the select-like primitives would then be defined over arbitrary futures and take ownership of their contents -- so the model basically can't work unless your futures have a "put toothpaste back in the bottle" method, which, you know, they don't.

This memory is _highly specific_ and yet I'm not sure it's not wrong.)

@charlotte

Okay, maybe I'm doing violence to the intended meaning of the post -- they're apparently saying "this is a way to implement that functionality," maybe they don't want you to literally put code like this into your codebase.

I guess my approximate thought was "this is 95% Rust-specific plumbing -- what the hell is going on here?"

@pyrex
In the simplest possible design of an async runtime, it'd check if both sources had any events every time the runtime gets woken up, so if any more complex runtime dropped events that would be a significant bug

@charlotte

I sure hope it's implemented like that! See my further blathering, where I describe my vague recollection, which I don't know is correct.

@pyrex
Yeah the actual Future plumbing is kind of arcane but honestly the main time I have to write it is with 3rd party async primitives like `AsyncRead`

@pyrex

I'm sorry to poke about this in this particular way, but they _are_ implementing a bunch of async primitives from scratch in the written code. I'm not sure most people are expected to do that?