[falcolas]

> My only complain is that Python is not great at async operations

For most asynchronous IO operations, the old standby of threads works an absolute treat. There are certain pathological corner cases where a single thread can be blocked, but for the other 99.9% of use cases, it works fantastically.

Build your synchronous and stateless web code and throw it into a thread. Done. Even the more complex cases of a single worker needing to make multiple asynchronous calls can be handled easily without even having to leave the standard library.

Now then, this falls apart a bit when you have to deal with global state (and the assorted locks and deadlocks), but most web backends aren't too hard to write statelessly.

[greenshackle2]

But spawn enough threads in Python and you risk entering scheduling hell, thanks to the global interpreter lock. EDIT: if you are CPU bound at all. If you are really really IO bound it's not a problem.

Event-driven programming is my go-to for nontrivial backend async in Python, and in Python 2 you almost certainly want to use a third party library for that.

(But maybe I'm just lazy. I try to avoid the headache of threads in python if I can.)

Python 3 has asyncio, which looks good, though I havn't used outside of toy projects at this point.