People use that blog post as a slam dunk over the years, but my reaction has always been "yes, fine, but that's a small price to pay".

For example, very rarely in my experience does a function switch between synchronous and asynchronous. So when it does happen and I have to update upstream call sites, it's not so frequent nor painful enough to damn the whole abstraction and then go "see? it sucks".

When people suggest an alternative abstraction like Go, I compare my 50 lines of WaitGroup code in Go to things like `await Promise.all([prom1, prom2])` in Javascript. It's all just trade-offs.

I don't think that async/await is about to make things faster. It's about to run things things in parallel. For example, you can run long tasks with making your GUI unresponsive.

I feel like I could untangle some this, but not without re-writing a version of the article that this thread is about. Like async/await adding overhead and therefore being slower than direct calls, if you use them incorrectly, is actually accurate but not a legitimate problem (they make up for their overhead when used as designed, specifically on slow endpoints).

Also, async/await doesn't cut you off from anything. You just need to understand what is and isn't an asynchronousable end-point, people get confused then start throwing random keywords around without really grasping how it works (e.g. "if I await everything, it is concurrent, right?!" then write a bunch of code that actually runs synchronously but with tons of overhead).

I guess this is my nice way of saying: You need to read this very article. It corrects your concerns, and shows you when async/await is useful and likely when it isn't.