I've been working on a legacy internal python system that suffers from most of the complaints here (and in the excellent COST paper Rachel links at the bottom).
The problems alluded to are, yes, solvable in python. But they also seem endemic in python systems.
When everyone who uses the tool uses it wrong, maybe it's not the user's fault.
(That said, I generally do think there's a time and place for python systems or web apps. That time is generally when speed and maintainability is significantly less important than flexibility)
> The problems alluded to are, yes, solvable in python. But they also seem endemic in python systems.
>
> When everyone who uses the tool uses it wrong, maybe it's not the user's fault.
Yes, though that doesn't mean it is necessarily the code's fault.
Honestly, I was very confused by this article, because I thought everyone understood what was going on, the trade-offs involved, and how that ought to impact your design decisions.
It's not that Gevent'd Gunicorn is intrinsically a bad thing. You're going for cooperative multi-tasking/concurrency, so no preemptive multi-tasking support. This creates potential challenges with fair scheduling if you have real-time constraints like timeouts... so you design accordingly.
One of the advantages of this model is you do indeed need less memory (and often a little less CPU) to handle high load levels. It's not like you are intrinsically better off if you use Python in a forking model. You can still end up so CPU bound that you timeout handling requests... the only difference is you'll get fairer splitting of the CPU's time across tasks. It can actually get worse if you get lost in an infinite series of context switches (yes, there are ways to mitigate this problem... although they can create fair scheduling problems... it's a natural tension), or worse still, start swapping.
If the notion that running out of CPU might mean you have timeouts hasn't occurred to you...
> When everyone who uses the tool uses it wrong, maybe it's not the user's fault.
I'm not the GP, but I guess that a tool that is
> quick to use and helps you solve problems faster with its gigantic, mature ecosystem that lets you focus on your business logic
Can never cover all bases perfectly, and is generally great when starting out, but ultimately not built to be very forgiving when grown too much.
> now you're boxed into an expensive corner and you need to figure out how to scale
When you get to this point, and the requirements start to be more focused on performance, then it's time to start switching Python out. That does not devaule Python in the earlier stages of development and operation.
The point being that Python is the right tool for getting stuff working quick, not to getting stuff executing quick.
The problems alluded to are, yes, solvable in python. But they also seem endemic in python systems.
When everyone who uses the tool uses it wrong, maybe it's not the user's fault.
(That said, I generally do think there's a time and place for python systems or web apps. That time is generally when speed and maintainability is significantly less important than flexibility)