[hombre_fatal]

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.

[za3faran]

golang's approach is anemic, so it's not an either/or situation.

Take a look at Java's approach (Loom + Futures + Structured Concurrency). It allows you to be succinct yet avoid the explicit async/await approach.