←back to thread

Python has had async for 10 years – why isn't it more popular?

(tonybaloney.github.io)
320 points willm | 4 comments | 02 Sep 25 17:24 UTC | HN request time: 0.002s | source
Show context
atomicnumber3 ◴[02 Sep 25 17:41 UTC] No.45106455[source]▶
The author gets close to what I think the root problem is, but doesn't call it out.

The truth is that in python, async was too little, too late. By the time it was introduced, most people who actually needed to do lots of io concurrently had their own workarounds (forking, etc) and people who didn't actually need it had found out how to get by without it (multiprocessing etc).

Meanwhile, go showed us what good green threads can look like. Then java did it too. Meanwhile, js had better async support the whole time. But all it did was show us that async code just plain sucks compared to green thread code that can just block, instead of having to do the async dances.

So, why engage with it when you already had good solutions?

replies(24): >>45106558 #>>45106616 #>>45106659 #>>45106663 #>>45106684 #>>45106758 #>>45107048 #>>45107148 #>>45107247 #>>45107394 #>>45107701 #>>45107865 #>>45108486 #>>45108978 #>>45109142 #>>45109610 #>>45109958 #>>45110033 #>>45110052 #>>45110805 #>>45111877 #>>45111901 #>>45113010 #>>45113188 #
throw-qqqqq ◴[02 Sep 25 17:51 UTC] No.45106616[source]▶
> But all it did was show us that async code just plain sucks compared to green thread code that can just block, instead of having to do the async dances.

I take so much flak for this opinion at work, but I agree with you 100%.

Code that looks synchronous, but is really async, has funny failure modes and idiosyncracies, and I generally see more bugs in the async parts of our code at work.

Maybe I’m just old, but I don’t think it’s worth it. Syntactic sugar over continuations/closures basically..

replies(5): >>45106787 #>>45106801 #>>45106917 #>>45109308 #>>45109618 #
1. Uptrenda ◴[02 Sep 25 21:54 UTC] No.45109618[source]▶
I'm a person who wrote an entire networking library in Python and I agree with you. The most obvious issue with Python's single-threaded async code is any slow part of the program delays the entire thing. And yeah -- that's actually insanely frigging difficult to avoid. You write standard networking code and then find out that parts you expected to be async in Python actually ended up being sync / blocking.

DESPITE THAT: even if you're doing everything "right" (TM) -- using a single thread and doing all your networking I/O sequentially is simply slow as hell. A very very good example of this is bottle.py. Lets say you host a static web server with bottle.py. Every single web request for files leads to sequential loading, which makes page load times absolutely laughable. This isn't the case for every python web frame work, but it seems to be a common theme to me. (Cause: single thread, event loop.)

With asyncio, the most consistent behavior I've had with it seems to be to avoid having multiple processes and then running event loops inside them. Even though this approach seems like its necessary (or at least threading) to avoid the massive down sides of the event loop. But yeah, you have to keep everything simple. In my own library I use a single event loop and don't do anything fancy. I've learned the hard way how asyncio punishes trying to improve it. It's a damn cool piece of software, just has some huge limitations for performance.

replies(1): >>45112383 #
2. fulafel ◴[03 Sep 25 04:58 UTC] No.45112383[source]▶
bottle.py is a WSGI backed framework, right? So it's agnostic about whether you are running with threads, fork, blocking single thread IO, gevent, or what.
replies(1): >>45112434 #
3. Uptrenda ◴[03 Sep 25 05:14 UTC] No.45112434[source]▶
Umm, acktually... (the default server is non-threaded and sequential. It was an example.)
replies(1): >>45112902 #
4. ◴[03 Sep 25 06:45 UTC] No.45112902{3}[source]▶