5 Answers
5

I would say that there are real technical issues behind it. The Ruby implementation (at least ruby 1.8) is not designed for concurrency : ruby 1.8 has a global interpretor lock, and it uses green threads instead of OS native threads.

So, for a web application to scale, you have to run multiple ruby interpretors, and make them work together.

Note : I am not into web development, and It's been a long time I haven't used ruby. Maybe ruby 1.9 or JRuby don't have these issues. Maybe the global lock is not a real problem for scaling up.

I'm not a hard-core Rubyist but I bet I can think of the come-back: You can do much more with a single line of Ruby than you can with a single line of C++. Seriously, why is "line of code" a good base unit?
–
JamesApr 11 '11 at 9:04

2

Your mixing up scalability with performance; scalability is ability to increase the performance by throwing hardware at the problem.
–
dan_waterworthApr 11 '11 at 12:56

3

My question is, what the heck is up with vpascal?
–
quanticleApr 11 '11 at 13:34

2

That's Ruby 1.6.7, which is more than a little outdated.
–
mipadiApr 11 '11 at 14:46

I'm guessing it has to do with the fact that Rails is based around the Active Record pattern, which is quick and easy to get started with, but can slide into a constant refactoring battle as your app's complexity increases. I think that's why you hear about startups in particular having troubles: they're able to get something working quickly, but as they add features, the complexity grows and that's when the trouble starts.

Speaking from experience creating a Rails application, I will second this. Not just in scaling but Rails in general runs into issues when you need to do more than just reading/writing a single record from a database. If you need some kind of complex business logic, for instance, Rails can hinder you more than it benefits you. It's still a superb framework and a beautiful language, but it's not perfect (not that anything is "perfect" in programming).
–
Wayne MApr 11 '11 at 13:37