Glad you published this Giles. I really think you hit the nail on the head in your criticism of rails, and not necessarily ruby. I think some of the framework decisions in the 3.0 release were kind "abstraction for abstraction's sake" moves. In other areas, I think the framework has pushed beyond what the language is capable of handling in a reasonable manner, from a performance perspective (I'm talking about development efficiency performance, not production performance).
No doubt, these features were implemented with good solid principles in mind. But, imo, at this point in Rails' lifecycle as a framework (something that has been in public release for 5+ years) performance (both production and in development) should have held more weight in the decision-making process than doing things for what appeared to be because they were the "right" things to do.
For one, the startup time of the framework is just, atrocious. If it takes me 15-30 seconds to boot up the framework (and on my quad core dual processor 8gb ram MBP running a small-to-medium-sized project, it does) just to run one test, that is just plain ridiculous. A lot of that time is spent loading the large dependency graph of gems with which most new rails apps these days are packaged. I think this trend -- rigorous packaging open source library code as a first-class dependency, instead of writing it yourself, or snapshotting that actual code in your SCM -- is a good thing. But I think the performance characteristics of the ruby language, and of the ruby community, make trying to cram 150+ gems into the load path and then require all of them, serially, in a single thread, unacceptably slow for modern web development.
I will say that I think the situation has improved quite a bit more recently, and the focus seems to be honing in more on development performance, but it might be a tad too late for me. I'm focused more on building api's than I am building "web apps". For that, sinatra is just a much simpler, faster and elegant stack IMHO.
No doubt, these features were implemented with good solid principles in mind. But, imo, at this point in Rails' lifecycle as a framework (something that has been in public release for 5+ years) performance (both production and in development) should have held more weight in the decision-making process than doing things for what appeared to be because they were the "right" things to do.
For one, the startup time of the framework is just, atrocious. If it takes me 15-30 seconds to boot up the framework (and on my quad core dual processor 8gb ram MBP running a small-to-medium-sized project, it does) just to run one test, that is just plain ridiculous. A lot of that time is spent loading the large dependency graph of gems with which most new rails apps these days are packaged. I think this trend -- rigorous packaging open source library code as a first-class dependency, instead of writing it yourself, or snapshotting that actual code in your SCM -- is a good thing. But I think the performance characteristics of the ruby language, and of the ruby community, make trying to cram 150+ gems into the load path and then require all of them, serially, in a single thread, unacceptably slow for modern web development.
I will say that I think the situation has improved quite a bit more recently, and the focus seems to be honing in more on development performance, but it might be a tad too late for me. I'm focused more on building api's than I am building "web apps". For that, sinatra is just a much simpler, faster and elegant stack IMHO.