Hard Deadlines, Soft Couch

This is going to be long, feel free to transfer this thread to the proper blog post. Also, feel free to thank me for spending my time on this. : )

"I really, really doubt that Twitter is in need of money to buy hardware."

Mike, take a second, and imagine yourself a one out of 2-4 guys who made a toy project. It got big and popular, but you weren't going that route. You probably have a lot of serious stuff on your hands, real ventures, business plans. Exposure of your toy project forces you to give interviews, answer for downtimes, and so on, but it's not what you're focusing on. It's not a matter of buying hardware. It's a matter of humans having only 2 hands, yet wanting to become successful. Very simple. How would you set your priorities? Would it be your #1 priority to help thousands of nameless, non-paying visitors who are probably working on something of their own that is profitable, and using your system for convenience? Simple logic. At most you'd be thinking how to use the user base for a profit. But twitter having money?? Puhlease! Just search Google for "twitter makes profit". All simply elaborations.

"As far as I'm concerned, in OS world everything except Apache is exotic."
Well, dear colleague, doesn't seem like you're concerned too far. Big projects are going with either heavily modified older versions of apache, or lighttpd, nginx, and so on. Apache is exactly what you'd usually dislike - a bloated server which supports everything, and sacrifices efficiency to shoot for wider admin audience. Other servers focus on certain things, which is what you'd expect in multi-server environment. A server responsible for responding to millions of requests shouldn't concern itself with script processing. Now when you look at it this way, is apache the right tool for the job? Sometimes. Do you notice a problem with your logic?

"if you abstract your SQL out, you make it so much more difficult to optimize it"
I would like to hear more on your complications of SQL abstraction, since this sentence has no argument. When you program using natural laws of OOP, you end up with ORM for your db, one way or another. And when your ORM makes things slow - you replace an abstracted db call in that particular method with a query that's faster. See how it works? Anywhere you can do that. What's even more fun - smart query caching decreases your database load by orders of magnitude - even more so with db abstraction. DB caches (such as memcached) use a query itself to identify a necessary resource. It means that the more generalized your query is, the more stuff is being cached. It also means that the more specific and "to the point" your query is - the more times you have bother database for each specific set of data. If on one page you'd have to fetch "select * from users where profile = 1" and on another you'd have "select * from users where profile = 1 inner join avatars on users.id = avatars.user_id", these two queries have same data fetched twice, the info from users table. You could avoid that by using abstraction and caching. Abstraction would split these queries into 2, and caching would take care of the one already mentioned.

"RoR has it's uses - like quick prototyping or light duty programming. If you try to use it for anything else, you run into trouble."
I used it for something else, have you? This argument is illogical, since there's no scientific method applied to get your conclusion. My experience showed no problems, and you have no experience. See the difference? Stop resorting to twitter for your judgement. It's old and boring. All you're accomplishing is making yourself more comfortable, and losing an opportunity to expand your horizons.

It's funny that your attempt at turning my airplanes comparison against me is similar to high school taunt. Sounds cool, but there's no substance. Rails pays at least 120k right now. It gets more and more use every day. I'm sorry to see you choosing to stand aside getting old quietly, intentionally losing touch with technology.

Not gonna start on auto-testing (i never mentioned that at all), but wanna add 1 more thing.

Rails is hard. It's harder to learn than Drupal, and harder to learn than plain programming. That's because - first of all - Rails is on Ruby (a complex beautiful language), second of all - Rails encourages you to use best practices. If you think that newbies program on rails because it's simple - that goes as far as some macro-style declarative programming copied from books. To do anything real, you have to be truly interested in best practices and computer science in general. You have to explore beautiful language, and its abilities such as blocks, closures, etc. You have to learn your discrete math, algorithms, etc. There's a reason why rails costs so much, while average php is half of rails salary on average, a reason besides scarcity.