I'm not the biggest Python fan, but when I was forced to use it using async disabled a bunch of things... like the debugger. Not a fan.
Python has had async for 10 years – why isn't it more popular?
121–130 of 305 posts
Re: Python has had async for 10 years – why isn't it more popular?
#122A little history... During development, asyncio was called tulip. A quick search turns up this talk by Guido: https://www.youtube.com/watch?v=aurOB4qYuFM I seem to recall that Guido was in touch with the author of Twisted at the time, so design ideas from that project may have helped shape asyncio. https://twisted.org/ Before asyncio, Python had asyncore, a minimal event loop/callback module. I think it was was intro…
asyncore actually worked well, unlike asyncio
so of course in their infinite wisdom, they removed it
Re: Python has had async for 10 years – why isn't it more popular?
#123I 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 the wrapper isn't async.
Coroutines vs futures vs tasks are odd. More than is pleasant, you have one but need the other for an API for no intuitive reason. Some waiting functions work on some types and not on others. But you can usually easily convert between them - so why make a distinction in the first place?
I think if you create a task but don't await it (which is plausible in a server type scenario), it's not guaranteed to run because of garbage collection or something. That's weird. Such behaviour should be obviously defined in the API.
Re: Python has had async for 10 years – why isn't it more popular?
#124Exceptions are difficult to deal with. Also, while they've had async for 10 years it has changed quite a bit from the initial incarnation.
there are some Exception situations that are almost completely impossible to deal with
like guaranteeing a close() inside a finally
asyncio is a terrible, terrible library
Re: Python has had async for 10 years – why isn't it more popular?
#125The 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 is pretty good “green threads” on its own. Coroutines can be better, but they’re really solving an overlapping set of problems. Some the same, some different.
In JavaScript async doesn’t have a good way to nice your tasks, which is an important feature of green threads. Sindre Sorhus has a bunch of libraries that get close, but there’s still a hole.
What coroutines can do is optimize the instruction cache. But I’m not sure goroutines entirely accomplish that. There’s nothing preventing them from doing so but implementation details.
Re: Python has had async for 10 years – why isn't it more popular?
#126Earlier quoted context omitted.
Having to put "await" everywhere is very explicit. I'd even say it's equally explicit to a bunch of awkward closures. Why do you say it's less?
> Why do you say it's less Let me try to clarify my point of view: I don’t mean that async/await is more or less explicit than goroutines. I mean regular threaded code is more explicit than async/await code, and I prefer that. I see colleagues struggle to correctly analyze resource usage for instance. Someone tries to parallelize some code (perhaps naiively) by converting it to async/await and then run out of memory.…
>I don’t mean that async/await is more or less explicit than goroutines. I mean regular threaded code is more explicit than async/await code, and I prefer that.
More explicit in what sense? I've written both regular threaded Python and async/await Python. Only the latter shows me precisely where the context switches occur.
Re: Python has had async for 10 years – why isn't it more popular?
#127The 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.
The function color thing is a real concern. Am I wrong or did a python user originally coin that idea?
Re: Python has had async for 10 years – why isn't it more popular?
#128I was using gevent to get async benefits in Python 10+ years ago. It's a much nicer programming paradigm than async/await, in my opinion. Now working in Go where the same pattern is built into the language, I'm even more convinced.
Re: Python has had async for 10 years – why isn't it more popular?
#129The premise of the article is wrong. Async in Python is popular. I'd expect most new web backends to use it.
The article says SQLalchemy added async support in 2023 but actually it was 2020.
Re: Python has had async for 10 years – why isn't it more popular?
#130The 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…
For me, once I wanted to scale asyncio within one process (scaling horizontally on top of that), only two things made sense: rust with tokio or node.js. Doing async in python has the same fundamental design. You have an executer, a scheduler, and event-driven wakers on futures or promises. But you’re doing it in a fundamentally hand-cuffed environment. You don’t get benefits like static compilation, real work-stealin…
I don’t know where Java is now but their early promise and task queue implementations left me feeling flat. And people who should know better made some dumb mistakes around thread to CPU decisions that just screamed “toy solution”. They didn’t compose.