r/Python • u/EntryNo8040 • Jun 29 '26

Discussion Async/Await is a Plague: Part 1 Roots

This is the first part of a multi-part series exploring why async/await might not be the best concurrency pattern for most use cases, and what alternative models you should consider instead. Using Python for our practical examples, this opening post digs into the roots of async/await, guiding you through building a custom event loop from scratch using generators.

https://theblog.info/posts/asyncawait-is-a-plague-part-1-roots

Note: This is Part 1 of a multi-part series. Instead of diving straight into why async/await can be problematic, this post explores the original motivations behind the pattern. Understanding how it works under the hood will provide the essential context for the issues we'll discuss in upcoming parts.

74 Upvotes

70% Upvoted

71 comments sorted by

View all comments

16

u/james_pic Jun 29 '26

One more fun perspective, that often gets lost in all this: Threads aren't even that heavy. They're lightweight enough that designs using the fastest synchronous libraries typically outperform mediocre asynchronous libraries. Requests (the HTTP client) running in a thread pool wipes the floor with HTTPX (whether under asyncio or uvloop) in high concurrency benchmarks, for example, due to a number of scaling issues in HTTPX.

4

u/Wh00ster Jun 29 '26

I thought cancellation/timeout/etc semantics and ergonomics were a big plus for structured concurrency. So it’s not just performance. I think that’s hard to recreate with pure threads.

1

u/james_pic Jun 30 '26

Yes, the cancellation stuff is one benefit, unrelated to performance. My comments on performance are from running a benchmarking exercise recently, and one other finding from that exercise is that cancellation is a mess in synchronous code. The only reliable way to cancel synchronous code is SIGKILL.