[seabrookmx]

You not only leave performance on the table (which depending on your use case/environment, may not matter if you can just throw more threads at it) but also some developer ergonomics.

asyncio.gather is a lot less code than having to manage a thread pool or something like Celery with all it's underlying infrastructure.

If you're in an ecosystem where a lot of the async boilerplate is free/cheap (ex: FastAPI) then the developer overhead of sprinkling awaits on your I/O bound calls is pretty low IMO.

[bigstrat2003]

Performance aside (which I would argue is premature optimization, as most programs will not feel the theoretical overhead of threads), async is a bad approach for developer ergonomics. Threads are so much easier to work with and reason about than async. There are reasons to use async (like if you're in the rare case when thread overhead is noticeable), but developer ergonomics are absolutely not a reason.

[seabrookmx]

Say I need the results from two expensive REST API calls, so I want to run them concurrently. Managing a thread pool you find a _better_ experience than

one, two = await asyncio.gather(callOne(), callTwo())

?

[wtetzner]

Doesn't Python support futures?

    with ThreadPoolExecutor() as executor:
        one, two = executor.map(lambda f: f(), [callOne, callTwo])

I'm sure you could write a nicer helper function that's more similar to gather as well.

[seabrookmx]

Sure, in a web server context you'd probably want to instantiate that executor globally and re-use it, Then you could write helper functions around that. But it's still considerably more code and legwork than the async alternative, while also being slower and using more memory if you care about those things.

[ian_j_butler]

> something like Celery with all it's underlying infrastructure.

Unpopular opinion, but combining this with the other "no thanks" sentiments in this subthread is the right answer. Your app is so complicated you need async? Then it's complicated enough that you can benefit from infrastructure. I don't want to watch coworkers try to badly rebuild message queue or scheduling semantics in an application code base. Just use infrastructure that's made by people who know what they are doing. That was problematic in 2015, but in 2026 it's a bit of docker, and it's not just about web/microservices. Very easy for sufficiently complex apps to simply leverage a local sandbox of celery, redis, graphdb's and whatever. Stand-alone is overrated since we don't have to do it anymore.. app devs should get more comfortable working with ensembles like this so they have access to best-in-class solutions.

You don't like infrastructure AND have such a need for performance AND don't want threads or multiprocess? Consider using another language. Async is mostly a solution in search of a problem, and the enduring popularity of TFA goes to show this has been the right conclusion for ~10 years.

[seabrookmx]

I said nothing about "stand-alone" services. I'm all about using the right solution to the problem. We run on Kubernetes and have access to message queues. But if all I want to do is make a couple of HTTP calls concurrently, I don't think I should have to manage a thread/process pool to do so, or lean on a message queue or redis based RPC mechanism. In an async context I can do this with a single line of code.

Every rich client-side experience in your browser is written using async code in Javascript or Typescript, as is every electron app. Every developer at my company is comfortable with this pattern, and frameworks like FastAPI make this a similarly smooth experience when using Python.

If async was a solution in search of a problem, it wouldn't have been stolen from C# and added to Rust, Python, Kotlin, etc. The engineering effort required to bring this solution to all these languages is immense, so I'm clearly not the only person seeing value in it.