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?

> 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 don’t think it’s worth it. Syntactic sugar over continuations/closures basically..

As somebody who's written and maintained a good bit of Python in prod and recently a good amount of server-side typescript... this would be my answer.

I'd add one other aspect that we sort of take for granted these days, but affordable multi-threaded CPUs have really taken off in the last 10 years.

Not only does the stack based on green-threads "just work" without coloring your codebase with async/no-async, it allows you to scale a single compute instance gracefully to 1 instance with N vCPUs vs N pods of 2-vCPU instances.

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.

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.

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.

>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).

The problem is not python, it's a skill issue.

First of all forking is not a workaround, it's the way multiprocessing works at the low level in Unix systems.

Second of all, forking is multiprocessing, not multithreading.

Third of all, there's the standard threading library which just works well. There's no issue here, you don't need async.

I also think asyncio missed the mark when it comes to it's API design. There are a lot of quirks and rough edges to it that, as someone who was using `gevent` heavily before, strike me as curious and even anti-productive.

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 agree with you, I think. It's hard to figure out your own position when it comes to multithreading and multitasking APIs.

To me, Go is really well designed when it comes to multithreading because it is built upon a mutual contract where it will break easily and at compile time when you mess up the contract between the scheduling thread and the sub threads.

But, for the love of Go, I have no idea who the person was that decided that the map data type has to be not threadsafe. Once you start scaling / rewriting your code to use multiple goroutines, it's like you're being thrown in the cold water without having learnt to swim before.

Mutexes are a real pain to use in Go, and they could have been avoided if the language just decided to make read/write access threadsafe for at least maps that are known to be accessed from different threads.

I get the performance aspect of that decision, but man, this is so painful because you always have to rewrite large parts of your data structures everywhere, and abstract the former maps away into a struct type that manages the mutexes, which in return feels so dirty and unclean as a provided solution.

For production systems I just use haxmap from the start, because I know its limitations (of hashes of keys due to atomics), because that is way easier to handle than forgetting about mutexes somewhere down the codebase when you are still before the optimization phase of development.

Green threads can be nicer to program in, but it’s not like there’s no cost. You still need a stack for every green thread, just like you need one for every normal thread. I think it’s worth it to figure out a good system for stackless async. Something like Kotlin is about as good as it gets. Rust is getting there, despite all the ownership issues, which would exist in green threads too.

> 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'll be sold on this when a green thread native UI paradigm becomes popular but it seems like all the languages with good native UI stories have async support.

pair this with needing async in depth and that's exactly it. The whole network stack needs to be async-first and all the popular networking libraries need to have been built on that. Many of those libraries are already C-extension based and don't jibe well with the newer python parts in any way.

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.

Java has had green threads since day one, most vendors ended up going red threads full way, and now we're back into green and red world.

The main difference being that now both models are simultaneously supported instead of being an implementation detail of each JVM.

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!)

It might have been too little but it wasn’t too late.

Generations of programmers have given up on downloading data async in their Python scripts and just gone to bash and added a & at the end of a curl call inside a loop.

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-stealing, a large library ecosystem, or crazy performance boosts. Except in certain places in the stack.

Using fastapi with async is a game-changer. Writing a cli to download a bunch of stuff in parallel is great.

But if you want to use async to parse faster or make a parallel-friendly GUI, you are more than likely wasting your time using python. The benefits will be bottlenecked by other language design features. Still the GIL mostly.

I guess there is no reason you can’t make tokio in python with multiprocessing or subinterpreters, but to my knowledge that hasn’t been done.

Learning tokio was way more fun, too.

green thread have pitfalls too, like this: https://news.ycombinator.com/item?id=39008026

I feel like async is just an easier way to reason about something but it leaves out a lot of cheating open ; tough sometimes it's just more comfortable to write - but that cheating comes with a lot of hidden responsibilities that are just not presented in python (things like ownership) - even tough it present tools to properly solve these issues - anyone who would really want to dive into technical wouldn't choose python anyway

Even in Java, async is rarely the right solution. I'm sure in situations where it's needed, Python's async would be used. For instance, it would be good for reducing resource usage in any kind of small service that dynamically scales. The workarounds are much more expensive but that doesn't matter unless you're already resource constrained.

Even then, nginx might be a netter solution.

i agree, also add to that, that many python modules are foss projects that are maintained on a limited basis or budget. Refactoring code that may have some unsafe async routines would be costly for an org, and dreadful for recreation. So you can either have a rich library of modules, or go async and risk something you need not working then having to find a workaround. Personally, if parallelism is important enough, i use ctypes and openmp. If i need something more portable, i have a few multiprocessing wrappers that implement prange and a few other widgets for shared memory.

forking and async are totally different things.

"Then java did it too." Java had green threads in 1.0. They were removed. Then Java added virtual threads.

You make a very good case for why python's async isn't more prevalent, but I think this is not painting the full image.

Taking a general case, let's say a forum, in order to render a thread one needs to search for all posts from that thread, then get all the extra data needed for rendering and finally send the rendered output to the client.

In the "regular" way of doing this, one will compose a query, that will filter things out, join all the required data bla bla, send it to the database, wait for the answer from the database and all the data to be transferred over, loop over the results and do some rendering and send the thing over to the client.

It doesn't matter how async your app code is, in this way of doing things, the bottle neck is the database, as there is a fixed limit on how many things a db server can do at once and if doing one of these things takes a long time, you still end up waiting too much.

In order for async to work, one needs to split the work load into very small chunks that can be done in parallel and very fast, therefore, sending a big query and waiting for all the result data is out of the window.

An async approach would split the db query into a search query, that returns a list of object ids, say posts, then create N number of async tasks that given a post id will return a rendered result. These tasks will do their own query to retrieve the post data, then assemble another list of async tasks to get all the other data required and render each chunk and so on. Throw in a bunch of db replicas and you get the benefits of async.

This approach is not generally used, because, let's face it, we like making the systems we use do complicated things, eg complicated sql requests.