|
|
|
|
|
|
by collinmanderson
1417 days ago
|
|
|
Yes, though I do think the python async ecosystem is gradually moving from a "3rd class citizen" to a "2nd class citizen". There are sync+async libraries like HTTPX that are gaining support. I don't expect it to really ever be a "1st class citizen" (supported as well as sync in pretty much every library everywhere) because of backward compatibility and ultimately async is just harder to program. Sometimes developer time is more important than the performance wins of async. |
|
|
Also, a fair fraction of applications don't see a meaningful benefit compared to other things the developers could be spending time on. Async is not only harder to write in many cases but can force you to deal with new problems which might be harder to manage (e.g. if you use non-trivial amounts of memory, bounding your peak usage can be a challenge).
I've used async a fair amount and it's worked really well in network-heavy uses (HTTPX is really great) but outside of those the savings have been a lot less than people thought, independent of the language used (I'm thinking of a colleague who spent a lot of time trying to beat classic Python with Go and ended up with about a 10% win after a month or so of work because the problem had enough CPU/memory contention to prevent greater savings — that's not a trivial win but it definitely wouldn't have been enough to justify changing languages on its own).