Live data from Hacker News

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

tonybaloney.github.io

181–190 of 305 posts

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

#181
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…

Wouldn't the old school style be more like rust async? Simple structs that you poll whenever you need to explicitly. No magic code that looks synchronous but isn't.

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

#182
Wouldn't this be like asking why bit packing/flipping isn't more popular in python? In general, it just isn't necessary for the vast majority of programs people are likely to write using python.

Which isn't to argue that they did a good or a bad job adding the ability to the language. It just isn't the long pole in performance concerns for most programs.

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

#183
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…

The API complexity really threw me when I last tried async python. It's very different from other async systems and is incredibly different from gevent or twisted which were popular when I was last writing server python.

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

#184

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.

Which is really funny because the linux kernel doesn't do async for file writes :D

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

#185

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 think what they mean is that there are no blocking functions in the standard library except alert, prompt, and confirm. ( are there any others?)

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

#186

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

JavaScript’s Promises were of course heavily influenced by Twisted’s Deferreds in Python, from the days before async/await.

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

#187
post #38

It added intrusive- codebase-wide- functionality that more or less could have been done with other (thread-based) approaches. AWSCLI was broken for over a year- we had to do a ton of work to deal with the various packaging issues. Don't break userspace.

Why was awscli written in python? Bad decision to begin with. Hey! We have a product that we clearly want to release worldwide. Let's build it on something that doesn't have Unicode. Or any real threading. And is slow as hell. You picked a platform that was going to have to break user space. At least it wasn't JavaScript

Doesn’t have Unicode? What the heck?

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

#188
I generally like Python. I'm not a hater but I don't treat it like a religion either.

Async Python is practically a new language. I think for most devs, it's a larger than than 2 to 3 was. One of the things that made python uptake easy was the vast number of libraries and bindings to C libraries. With async you need new versions of that stuff, you can definitely use synchronous libraries but then you get to debug why your stuff blocks.

Async Python is a different debugging experience for most python engineers. I support a small handful of async python services and think it would be an accellerator for our team to rewrite them on Go.

When you hire python engineers, most don't know async that well, if at all.

If you have a mix of synchronous and asynchronous code in your org, you can't easily intermix it. Well you can, but it won't behave as you usually desire it to, it's probably more desirable to treat them as different code bases.

Not to be too controversial, but depending upon your vintage and they was you've learned to write software I think you can come to python and think async is divine manna. I think there are many more devs that come to python from datascience or scripting or maybe as a first language and I think they have a harder time accepting the value and need of async. Like I said above, it's almost an entirely different language.

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

#189
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…

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…

> 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 the wrapper isn't async.

Sorry for the possibly naive question. If I need to call a synchronous function from an async function, why can't I just call await on the async argument?

    def foo(bar: str, baz: int):
      # some synchronous work
      pass
    
    async def other(bar: Awaitable[str]):
      foo(await bar, 0)

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

#190

Earlier quoted context omitted.

FWIW Python got async/await before JavaScript did. I believe at the time the main inspiration was C#.

JavaScript was always single-threaded asynchronous, the added async/await keywords were just syntactic sugar. Node.js became popular before it as well, though I found at the time it was difficult to avoid callback hell similar to using libuv directly in C.

async/await was syntactic sugar in C# as well. Callbacks are a natural way to do async so it's no surprise.

And while Python implements async directly in the VM, its semantics is such that it can be treated as syntactic sugar for callbacks there also.

Post reply on HN