This is a _very_ funny article to me because at the end he basically says it's much nicer to use threads. I don't think anyone who has written an actually complex asynchronous application would agree.
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.
Yeah in my opinion it's one of the worst implementations of async runtime. Similarly with Python. It's not significantly faster, it can often times actually be slower, and the moment you write the async or await keywords in your code you've just cut yourself off from about 80% of what the language ecosystem has to offer.
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.
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.
1. Running things in parallel is always about making things faster. (For example, putting a long-running task on a background thread is about making the main thread faster).
2. We already have a way of making things run in parallel: threads and processes.
See the first code example in the fine article. The OS
Yeah it depends on what you're doing. If you're doing a lot of IO probably makes sense. Not running long tasks tho. I don't think that's a good use in Python at least.
I don't think you can ever make it not leaky, especially if native resources or certain types of locks are involved at some point. This would also apply to green threads, which means you're still using async/await - it just looks completely synchronous.