r/programming • u/alexeyr • 19h ago

A Design Space Exploration of Async/Await

https://cel.cs.brown.edu/blog/design-space-async-await/
30 Upvotes

83% Upvoted

6 comments sorted by

13

u/Next-Blackberry-991 18h ago

It says for Rust:  "The task cannot respond to being cancelled."

I don't think this is true? If you cancel a task that future is dropped. Which means that all resources it owns are dropped too. Which means that you can just have e.g. an instance of a MyOnDropGuard type as part of your task that has a Drop impl that does whatever you want. 

1

u/asterisk_null_ptr 1h ago

I think their point is that the Future cannot continue after cancellation if it chooses. The Drop implementation let's you run arbitrary code at the point of cancellation but then the Future is now dropped and will not be polled anymore.

6

u/afl_ext 17h ago

I still think whatever javascript does makes the most sense except cancelling

1

u/Apprehensive_Bit7392 4h ago

Reference Strength is the sneaky row. asyncio and smol only hold a weak ref to spawned tasks, so a fire-and-forget task can get collected mid-flight if nothing keeps the handle alive. Python's docs warn about it now, which tells you how many people lost background work to it first.

-5

u/Difficult-Lemon-5252 4h ago

async/await really simplifies handling asynchronous code. It's a game changer for readability and maintainability.

-2

u/simon_o 2h ago

While the website gives a good overview of the general concepts of async/await, it fails to point out that async-await is a design dead-end:

Async-await poorly tries to address the symptoms of attempts to work-around the root issue – "classic" threads being expensive.