That was the purpose of my second paragraph, but maybe I didn't get the point across enough. I don't think Rails is bad, not at all. I think Rails is great fo

That was the purpose of my second paragraph, but maybe I didn't get the point across enough. I don't think Rails is bad, not at all. I think Rails is great for getting projects up and running quickly, and for easily adding to the projects later on. You simply need to expend some energy on optimization (and reliability) once you find yourself growing to sizes that test your current code base. This could involve writing some frequently used code in a low-level language, rewriting a Rails function you're using which does more than you really need into straight Ruby, or reconsidering some of your SQL queries and handwriting some of those that are automatically handled. All I'm trying to say is that no matter who you are, at some point in the scaling process, you are going to have to revisit your code and make improvements. The great thing about Ruby, Python, Lisp, etc is the ability to throw a bunch of code down and get something running quickly. This code is inherently not optimal, and this is not a bad thing. Once you start to see problems, however, it's time to profile and re-think some of the things you are doing in order to improve your software overall.