upvote
> and is a major source why people dislike Rust's async

It's worth mentioning that there is, in fact, no language out there other than Rust that can even do this in the first place.

Some languages give the illusion that they support it by boxing the stack frame of async functions and letting a garbage collector deal with the consequences, but that comes with significant drawbacks too (additional GC pressure, heap allocation overhead, requiring a GC in the first place).

You can do it with C++ coroutines, but it's much harder to do correctly than in Rust if you want to maintain any sense of conviction that the system is correct.

The main reason that structured async concurrency would be so awesome to have is that it feels like Rust has the right set of features that could enable it with a set of constraints that are so much more attractive than any other language out there can provide - no overhead, "just works" with no drawbacks.

(For the record, you can actually get pretty far today using primitives like `FuturesUnordered` instead of `tokio::spawn` and similar, but this sidesteps the runtime's scheduler, so YMMV. This basically creates a task-local mini-scheduler for your futures, which may or may not be sufficient.)

reply
C++26 adopted senders/receivers (std::execution) as its official concurrency model, with the explicit aim of supporting structured concurrency. See https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p23...
reply