Top
Best
New

Posted by willm 9/2/2025

Python has had async for 10 years – why isn't it more popular?(tonybaloney.github.io)
324 points | 295 commentspage 6
cyberax 9/2/2025|
To add to this, async in Python is also plain buggy. For example, uvicorn is the most popular FastAPI server, and it leaks contexts across requests in the default installation.

The bug has been open for 2 years, with zero fucks given. The workaround is "just use libuv": https://github.com/encode/uvicorn/issues/2167

I've seen other such cases, and I just gave up on trying to use async.

fulafel 9/2/2025||
I think this is for the best. We don't want to end up like Rust. The complexity tradeoff suits Python's sweet spot even less (much less).
tonymet 9/2/2025||
async only helps with io-wait concurrency, but not cpu-bound concurrency.

async is popular in JS because the browser is often waiting on many requests.

command-line tools are commonly computing something. even grep has to process the pattern matching so concurrent IO doesn't help a single-threaded pattern match.

Sure there are applications where async would help a CLI app, but there are fewer than JS.

Plus JS devs love rewriting code very 3 months.

OhMeadhbh 9/2/2025||
I'm not the biggest Python fan, but when I was forced to use it using async disabled a bunch of things... like the debugger. Not a fan.
rcarmo 9/2/2025||
I've had no real issues with async, although I primarily use libraries like aiohttp and aiosqlite and even write my own helpers (https://github.com/rcarmo/aioazstorage is a good example).

The vast majority of the Python code I wrote in the last 5-6 years uses asyncio, and most of the complaints I see about it (hard to debug, getting stuck, etc.) were -- at least in my case -- because there were some other libraries doing unexpected things (like threading or hard sleep()).

Coming from a networking background, the way I can deal with I/O has been massively simplified, and coroutines are quite useful.

But as always in HN, I'm prepared for that to be an unpopular opinion.

JackSlateur 9/2/2025|
I share your experience

asyncio is easier than threads or multiprocess: less locking issue, easier to run small chunks of code in // (easier to await something than to create a thread that run some method)

zelphirkalt 9/4/2025||
There is no locking issue, if you don't mutate some global state from more than 1 thread at the same time. If you program mostly in pure functions, this is a non issue.
Meneth 9/2/2025||
KeyboardInterrupt (Ctrl+C) has been a problem wherever I've used python async. It should just work out of the box.
Areading314 9/2/2025||
I think explicit management of the event loop and the associated potential for grievous bugs has a lot to do with it.
mting 9/3/2025||
I would prefer to implement it using a synchronous approach and then switch to asynchronous at deployment.
throwawayffffas 9/2/2025||
The function coloring is a non starter for me.

I would just rather write JS where everything is async by default.

IshKebab 9/2/2025|
Everything is not async by default in JS.
fzzzy 9/2/2025|||
I think what they mean is that there are no blocking functions in the standard library except alert, prompt, and confirm. ( are there any others?)
steve_adams_86 9/3/2025||
Yeah, you can call async functions without specifying it as such and the script will just carry on regardless of how you're handling it. Totally weird, but also pretty cool. When I first started some 20 years ago that was a major foot gun for me, coming from PHP where functions always returned before the next one was called.
throwawayffffas 9/2/2025|||
I mean everything is running on the runloop, async/await, promises, and callbacks are different flavors of syntactic sugar for the same underlying thing.

In JS you can do:

   async function foo(){...}
   function bar(){foo().then(...);}
In python though async and sync code runs in a fundamentally different way as far as I understand it.
IshKebab 9/2/2025||
I'm not too familiar with Python async. The only time I used it was to get stderr and stdout out of a subprocess.run() separately. I think anyone using it for performance reasons is insane and should just switch to a more performant language.

Anyway I think the main difference is that in Python you control the event loop whereas in JS there's one fixed event loop and you have no choice about it.

bmandale 9/2/2025|
I don't like the idea of launching a whole thread for every concurrent task I want to do. But holy hell is it so much easier than figuring out how tf async works. If I wanted something super performant I wouldn't be using python in the first place.
More comments...