It solves only one problem, the name says it: Async I/O

If you do anything on the CPU or if you have any I/O which is not async you stall the event loop and everything grinds to a halt.

Imagine a program which needs to send heartbeats or data to a server in a short interval to show liveness, Kafka for example. Asyncio alone can't reliably do this, you need to take great care to not stall the event loop. You only have exactly one CPU core to work with, if you do work on the CPU you stall the event loop.

We see web frameworks built on asyncio but even simple API only applications constantly need to serialize data which is CPU-bound. These frameworks make no effort (and asyncio doesn't give us any tools) to protect the event loop from getting stalled by your code. They work great in simple benchmarks and for a few types of applications but you have to know the limits. And I feel that the general public does not know the limitations of asyncio, it wasn't made for building web frameworks on the async event loop. It was made for communicating with external services like databases and calling APIs.

> If you do anything on the CPU or if you have any I/O which is not async you stall the event loop and everything grinds to a halt.

But that's always going to be the case for single threaded code. If you're ready to use threads, then that integrates pretty seamlessly with asyncio by using an executor task.

> asyncio doesn't give us any tools to protect the event loop from getting stalled by your code

Again, check out executors: https://docs.python.org/3/library/asyncio-eventloop.html#asy...

Asyncio in Python and JS are very different beasts.

That's a problem - but its one that is common to all kinds of framework which make use of cooperative multitasking - whether they are in Python, Java (Netty, NIO, etc), C (Nginx, libevent, ...), C# or Rust.

All those frameworks trade off high performance if everything is well behaved against easy of use and potential of very bad performance if some regression is introduced.

Whether that tradeoff ia a good one to take will depend on the application.

The key disadvantage is largely that it bifurcates the library base. Async libraries and sync libraries co-exist uneasily in the same program.

For nearly every popular library there is now a (usually inferior, less robust) async one. The benefits of Linus' Law are reduced.

Fair point. Async is a big enough idea that it probably warrants designing the language with it in mind. I guess another way of phrasing it would be that it violates the "there's only one way to do it" maxim, and the "two ways of doing it" circumstance necessarily came about because the idea was discovered long after the core language and libraries were already written.

Trifucates, since now there’s stdlib asyncio, and a popular trio async flavor too.

> What specifically is the problem with asyncio?

Watch the very NSFW (lots of swearing) but hysterically funny video "node.js is bad ass rock star tech" on youtube sometime ;). https://www.youtube.com/watch?v=bzkRVzciAZg

I like using it as well, but I've been bit several times by having runtime exceptions completely swallowed.

Let me guess. Using create_task() without await and assuming it will run to completion in the background to trigger some other event?

This is almost always the case of async tasks disappearing into the void. After shooting myself in the foot with this one time to many I have a hard rule to never use create_task. Instead make sure every single task ends up in some kind of gather() or wait() awaited from the top level. This will ensure any exceptions are propagated. If the number of tasks are dynamically created, while others are still ongoing, add them to a common list and restart your wait() call.

Yes, exactly this scenario.

:)

Its not that strange actually. If you compare it to threads, where you shoot off a thread which you never join(). It’s exactly the same scenario.

Any thread which doesn’t have a join needs a watchdog. Or register the unhandled exception handler.

Can’t remember if threads do this by default. Asyncio tasks for sure don’t, and they can’t really do it either, since a task in error state could be saved for later use for legitimate reasons. Closest you get is the warning printed to log about tasks that got GCd without ever being awaited, if you enable ASYNCIO_DEBUG=1