Sadly many ruby, python, and php devs will just use process supervisors as a bandaid to the problem. I understand that some people who aren't really programmers

Sadly many ruby, python, and php devs will just use process supervisors as a bandaid to the problem. I understand that some people who aren't really programmers need to run a few scripts sometimes. For them supervisors make sense. Your average shared hosting environment running wordpress with some random custom plugins will probably benefit from a max of 10 or 100 requests per child. For anyone who's job description involves writing software and owning it's performance and reliability, process supervisors are a crutch. A crutch to be used only until the memory leak is found and a patch submitted to the relevant project. A former colleague used to refer to the concept of software entropy. Like physical entropy, it tends to increase. It's both natural and inevitable. But as engineers we sometimes, for brief windows of time, have the ability to impose order on chaos. To locally decrease entropy. I've seen the end result of relying on process supervisors to work around frequent crashes and memory leaks. The result is that you end up with ruby processes with multigigabyte heaps, resulting in a stack that can only run a few dozen requests/s even on the beefiest of hardware. To be clear, I'm not saying don't ever use process supervisors. It's just that if they are saving your bacon multiple times a day something's wrong. I'm also not claiming that inefficient software will cause your company to fail. It's perfectly possible that your buffaloak architecture will keep running until your company dies of natural causes, but I believe that we should have enough professional pride to fight entropy, even if we're the only ones who know what we did.