> All the pitfalls of concurrency are there [in async APIs]
This is one of those "in practice, theory and practice are different" situations.
There is nothing in the async world that looks like a parallel race condition. Code runs to completion until it deterministically yields, 100% of the time, even if the location of those yields may be difficult to puzzle out.
And so anyone who's ever had to debug and reason about a parallel race condition is basically laughing at that statement. It's just not the same.
> Code runs to completion until it deterministically yields
No, because async can be (quote often is) used to perform I/O, whose time to completion does not need to be deterministic or predictable. Selecting on multiple tasks and proceeding with the one that completes first is an entirely ordinary feature of async programming. And even if you don't need to suffer the additional nondeterminism of your OS's thread scheduler, there's nothing about async that says you can't use threads as part of its implementation.
Idk, I work in typescript though but I do have race conditions that look exactly like those of concurrent software.
In particular promise.all([f,f,f]) where I want to ensure that I only Run the body of f a single time.