3 ms·
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 f
by bigstrat2003 5mo ago
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 5mo agoSay 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 5mo agoDoesn'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 5mo agoSure, 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.