[buremba]

I totally agree that Python is much less problem compared to Javascript but I think that it's not fair to compare a backend language to a frontend language. My only complain is that Python is not great at async operations so people have to create unstable async libraries such as gevent and it's usually cause trouble in production. Luckily Python 3 solves this problem but backward compatibility is one of the most important things that is important in a programming language. People usually develop backend services once and maintain it for years but frontend is subject to change more often.

[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.