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

191–200 of 305 posts

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

#191

Post by munificent »

throwawayffffas wrote: post #166
hinkley wrote: post #127

Earlier quoted context omitted.

The function color thing is a real concern. Am I wrong or did a python user originally coin that idea?

No it was a js dev complaining about callbacks in node. Mainly because a lot of standard library code back then only came in callback flavour. i.e. no sync file writes, etc.

I wrote it. :)

Actually, I was and am primarily a Dart developer, not a JS developer. But function color is a problem in any language that uses that style of asynchrony: JS, Dart, etc.

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

#192

Post by thomasahle »

throw-qqqqq wrote: post #66
lacker wrote: post #54

Earlier quoted context omitted.

I'm confused, I feel like the two of you are expressing opposite opinions. The comment you are responding to prefers green threads to be managed like goroutines, where the code looks synchronous, but really it's cooperative multitasking managed by the runtime, to explicit async/await. But then you criticize "code that looks synchronous but is really async". So you prefer the explicit "async" keywords? What exactly is…

First, I don’t mean to criticize anything or anyone. People value such things subjectively, but for me the async/sync split does no good. Goroutines feel like old-school, threaded code to me. I spawn a goroutine and interact with other “threads” through well defined IPC. I can’t tell if I’m spawning a green thread or a “real” system thread. C#’s async/await is different IMO and I prefer the other model. I think the a…

Comparing to Haskell, I think of "async" as the IO monad. It's nice to have all code that does IO flagged explicitly as such.

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

#193

Post by meowface »

pnathan wrote: post #64
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…

Async taints code, and async/await fall prey to classic cooperative multitasking issues. "What do you mean that this blocked that?" The memory and execution model for higher level work needs to not have async. Go is the canonical example of it done well from the user standpoint IMO.

gevent has been in Python for ages and still works great. It basically adds goroutine-like green thread support to the language. I still generally start new projects with gevent instead of asyncio, and I think I always will.

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

#194

Post by munificent »

xg15 wrote: post #149
mcdeltat wrote: post #123

Earlier quoted context omitted.

I think Python async is pretty cool - much nicer than threading or multiprocessing - yet has a few annoying rough edges like you say. Some specific issues I run into every time: Function colours can get pretty verbose when you want to write functional wrappers. You can end up writing nearly the exact same code twice because one needs to be async to handle an async function argument, even if the real functionality of…

I think the general idea of function colors has some merit - when done right, it's a crude way to communicate information about a function's expected runtime in a way that can be enforced by the environment: A sync function is expected to run short enough that it's not user-perceptible, whereas an async function can run for an arbitrary amount of time. In "exchange", you get tools to manage the async function while i…

> Maybe a useful approach for a language would be to make "colors" a first-class part of the type system and support them in generics, etc.

Rust has been trying to do that with "keyword generics": https://blog.rust-lang.org/inside-rust/2023/02/23/keyword-ge...

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

#195

Post by meowface »

ddorian43 wrote: post #33
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…

Because it sucks compared to gevent (green threads). But for some reason, people always disregard this option. They don't even read it. Like any comment with gevent is shadowbanned and it doesn't register in their mind.

I've used gevent for years and will probably never stop. I greatly prefer it (or Go) over asyncio.

People act like it's dead but it still works perfectly well and, at least for me, makes async networking so much simpler.

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

#196

Post by tonymet »

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.

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

#197

Post by mixmastamyk »

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?

That’s what walrus is for:

    future = lambda age: (
        print('Your age is:', age),
        older := age + 5,
        print('Your age in the future:', older),
        older,
    )[-1]

    print(future(20))

    # out
    Your age is: 20
    Your age in the future: 25
    25

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

#198

Post by pdonis »

meowface wrote: post #193
pnathan wrote: post #64

Earlier quoted context omitted.

Async taints code, and async/await fall prey to classic cooperative multitasking issues. "What do you mean that this blocked that?" The memory and execution model for higher level work needs to not have async. Go is the canonical example of it done well from the user standpoint IMO.

gevent has been in Python for ages and still works great. It basically adds goroutine-like green thread support to the language. I still generally start new projects with gevent instead of asyncio, and I think I always will.

I've used gevent and I agree it works well. It has prevented me from even trying to experiment with the async/await syntax in Python for anything significant.

However, gevent has to do its magic by monkeypatching. Wanting to avoid that, IIRC, was a significant reason why the async/await syntax and the underlying runtime implementation was developed for Python.

Another significant reason, of course, was wanting to make async functions look more like sync functions, instead of having to be written very differently from the ground up. Unfortunately, requiring the "async" keyword for any async function seriously detracted from that goal.

To me, async functions should have worked like generator functions: when generators were introduced into Python, you didn't have to write "gen def" or something like it instead of just "def" to declare one. If the function had the "yield" keyword in it, it was a generator. Similarly, if a function has the "await" keyword in it, it should just automatically be an async function, without having to use "async def" to declare it.

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

#200

Post by jacquesm »

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…

There are much better solutions for the same problems, but not in Python. If you really need such high throughput you'd move to Go, the JVM or Erlang/Elixer depending on the kind of workload you have rather than to much around with Python on something that it clearly was never intended to do in the first place. It is amazing they got it to work as well as it does but the impedance mismatch is pretty clear and it will never feel natural.
Post reply on HN