Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

tonybaloney.github.io

Post reply on HN
Print view View original

151–160 of 305 posts

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

#151

Post by xg15 »

int_19h wrote: post #144
xg15 wrote: post #70

I learned about the concept of async/await from JS and back then was really amazed by the elegance of it. By now, the downsides are well-known, but I think Python's implementation did a few things that made it particularly unpleasant to use. There is the usual "colored functions" problem. Python has that too, but on steroids: There are sync and async functions, but then some of the sync functions can only be called f…

Generators are orthogonal to all this. They are the equivalent of `function*` in JS. And yes, they are also coroutines, but experience has shown that keeping generators separate from generic async functions is more ergonomic (hence why C# and JS both do the same thing).

True. I think the connection is more a historical one became the first async implementation was done using generators and lots of "yield from" statements AFAIK.

But I think generators are still sometimes mentioned in tutorials for this reason.

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

#152

Post by int_19h »

dapperdrake wrote: post #140
mixmastamyk wrote: post #41

Earlier quoted context omitted.

> lambdas only permitting a single expression Use a tuple, maybe walrus, and return the last item[-1].

That idea sounds good. How do I get variables for not redoing long-running computations that depend on one-another? So, what if the third tuple value depends on the second and the second in turn depends on the first?

You can abuse list and sequence comprehensions for this. `for..in` is effectively a variable binding since you can target a freshly created list or a tuple if you need to bind a single value. So:

  [x
   for x in [some_complicated_expression]
   if x > 0
   for y in [x + 1]
   ...
  ][0]
That said, I wouldn't recommend this because of poor readability.

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

#156

Post by int_19h »

aquariusDue wrote: post #40
tschellenbach wrote: post #11

Yes, this!. Its a mess, some typing, some async. No standardization/ one way to do things. Literally goes against the original ZEN of python "There should be one-- and preferably only one --obvious way to do it : Aim for a single, clear solution to a problem. "

Cue the zen of python apologists explaining how we just don't get it and that with enough reframing it'll click. Snide remark aside, I actually like the Zen of Python as programming language folklore but in 2025 AD it's kinda crazy to pretend that Python actually adheres to those tenets or whatever you wish to call them, and I'd go as far as to claim that it does a disservice to a language flexible enough for a lot o…

It has never been literally true anyway, not even back when it was originally written.

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

#157

Post by throwawayffffas »

IshKebab wrote: post #153
throwawayffffas wrote: post #150

The function coloring is a non starter for me. I would just rather write JS where everything is async by default.

Everything is not async by default in JS.

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.

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

#158

Post by int_19h »

xg15 wrote: post #151
int_19h wrote: post #144

Earlier quoted context omitted.

Generators are orthogonal to all this. They are the equivalent of `function*` in JS. And yes, they are also coroutines, but experience has shown that keeping generators separate from generic async functions is more ergonomic (hence why C# and JS both do the same thing).

True. I think the connection is more a historical one became the first async implementation was done using generators and lots of "yield from" statements AFAIK. But I think generators are still sometimes mentioned in tutorials for this reason.

Implementing what was essentially an equivalent of `await` on top of `yield` (before we got `yield from` even) was a favorite pastime at some point. I worked on a project that did exactly that for WinRT projection to Python. And before that there was Twisted. It's very tempting because it gets you like 90% there. But then eventually you want something like `async for` etc...

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

#159

Post by jongjong »

atomicnumber3 wrote: post #14

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…

Yes and JS had a smooth on-ramp to async/await thanks to Promises.

Promises/thenables gave people the time to get used to the idea of deferred evaluation via a familiar callback approach... Then when async/await came along, people didn't see it as a radically new feature but more as syntactic sugar to do what they were already doing in a more succinct way without callbacks.

People in the Node.js community were very aware of async concepts since the beginning and put a lot of effort in not blocking the event loop. So Promises and then async/await were seen as solutions to existing pain points which everyone was already familiar with. A lot of people refactored their existing code to async/await.

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

#160

Post by Uptrenda »

throw-qqqqq wrote: post #30
atomicnumber3 wrote: post #14

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…

> 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 do…

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.

Post reply on HN