[VWWHFSfQ]

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.

[Someone1234]

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.

[ycuser2]

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.

[mpweiher]

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

[roflyear]

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.