←back to thread

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

(tonybaloney.github.io)
320 points willm | 1 comments | 02 Sep 25 17:24 UTC | HN request time: 0.204s | 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 #
1. a-dub ◴[03 Sep 25 03:07 UTC] No.45111877[source]▶
also most python usecases that are in the realm of things like high performance concurrent request servicing push it down into libraries that i think are often tied to a native network request processing core. (gunicorn, grpc, etc)

python is kind of a slow choice for that sort of thing regardless and i don't think the complexity of async is all that justified for most usecases.

i still maintain my position that a good computer system should let you write logic synchronously and the system will figure out how to do things concurrently with high performance. (although getting this right would be very hard!)