I adopted gevent/greenlets pretty early on and it has always felt better than asyncio, monkey-patching aside.

The two api issue basically means async is not backwards compatible. You can't just squeeze some async into an existing code base, You'd need new functions, libraries etc. You'd basically need to rewrite the entire codebase in async to see an ounce of perf improvements.

The problem, IMO, with asyncio is that its way, way too complicated. In my experience, anyio (https://github.com/agronholm/anyio) provides a much better interface on top of asyncio. And since it can use asyncio as a backend, it maintains compatibility with the asyncio ecosystem. FastAPI, for example, uses anyio.

One thing that I don't see being mentioned in any of the threads here talking about green threads is cancellation. A huge benefit, IMO, of anyio is that it makes cancellation really easy to handle. With asyncio, cancellation is pretty hard. And with green threads, cancellation is often impossible.

With the newest Python, I can use no-gil, so my threads automatically use multiple cores. With asyncio, even under no-gil, unless I use a base layer that offers parallelism, I am stuck to a single core by default, which doesn't make any sense in a multicore world. In contrast, with Rust's async, there is no such limitation.

The traditional argument against the above assertion has been that asyncio is good for I/O work, not for CPU work, but this constraint is not realistic because CPU usage is guaranteed to creep in.

In summary, I can use threading/process/interpreter pools and concurrent futures, considering I need them anyway, without really needing to introduce yet another unnecessary concurrency paradigm (of asyncio).

For comparison, I asked about async in the raku programming language (https://rakulang.org). While I don't know details, raku's design avoids function coloring ( https://www.reddit.com/r/rakulang/comments/1n8hjrr/async_in_...).

I adopted just the Clojure style of thinking in terms of immutable copies and it seems easier to move between synch and asynch conceptually as needed, although Clojure has some asynch parallelism automatically due to this paradigm as well.

It’s probably related to the fact that when they added “await” to JavaScript, it seemed to become the most popular keyword in the language overnight, just comical amounts of it in the average new JavaScript file in the wild.

async doesn't work if you need to do filesystem I/O.

With POSIX, you can only really do blocking filesystem I/O. There's an API for async I/O, where readiness of any read/write operation can either deliver a signal, or start a new thread. Neither of these scale at all. Things like select, poll, epoll all block, even with O_NONBLOCK.

So if your application needs to read files which may be large, or on a slow filesystem (or even networked filesystems!), you're now working with blocking I/O, at which point async can't help you.

---

Obviously this isn't the root cause of "why hasn't async taken over". It's just one of the many reasons which all pile up.

The main reason I've encountered is that async is generally an all-or-nothing thing. It's generally not possible to take an existing code base and just "add a little async here and there". The entire thing has to be restructured from the ground up for async. The gain has to be really major for this to be worthwhile, more so the better your existing code already works.

This is sort of like the article's Problem 3, but it's not just maintaining two APIs, it's even creating the second API in the first place.