The thread treats async/await as one design pattern. It hasn’t aged the same way across languages.

C# async/await on top of the TPL is doing different work from JavaScript’s promise model. The C# version composes with cancellation tokens, structured exception handling, and a real thread pool underneath. JavaScript coloured the language because it had to: single-threaded runtime, no alternative. Rust’s async is closer to C++’s coroutines: a state machine at the call site, no runtime by default, executors as libraries. Three different things wearing the same syntax.

C++ shipped without async for thirty years and got along on thread pools and condition variables. The async crowd is right that thread-per-connection breaks at c10k. The thread-per-connection crowd is right that almost nobody is at c10k. Both are right about different problems.

The question that matters isn’t whether async was a mistake. It’s whether each language imported the cost (function colouring, runtime overhead, debugger pain) for the workload it actually has. JavaScript had to. C# had a strong case. Rust’s case for embedded is excellent. Python’s case is the most contested of the four and the one that gets defended hardest.