http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto
> The main Rails application that DHH created required restarting ~400 times/day. That’s a production application that can’t stay up for more than 4 minutes on average.
http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto
> The main Rails application that DHH created required restarting ~400 times/day. That’s a production application that can’t stay up for more than 4 minutes on average.
Ruby and Rails are nowhere near fast
Is not what's being argued. What's being argued is that "not fast" and "fast enough" are not mutually exclusive. My experience with other "slow" languages (primarily Python) is that this is true; even when the language implementation, or the application stack on top of it, is objectively "slow" compared to a similar stack in another language, often it simply makes no difference because that "slowness" gets lost in the noise of all the other, much slower, things a web application has to do.
I'm reminded of a wonderful blog post from years and years ago that I unfortunately can't find, which showed a pie chart of realistic profiling data from an application -- majority of time spent in things like network I/O, talking to its database, etc. -- and had a tiny tiny little slice labeled "Template rendering". It then pointed out that according to many people (fights among Python templating systems were common then) that was the obvious place that needed to be optimized for performance, ignoring everything else in the pie chart.
http://david.heinemeierhansson.com/posts/31-myth-2-rails-is-...
That isn't a complaint about performance.