How did the "Rails can't Scale" meme start?

Question

One meme about Rails is that Rails can't Scale. Is it known how this meme started? Was there a particular blog post that argued this is the case?

• James: If you can answer the question "how [did] this meme start?" then it's not really a meme :-)

Answer 1

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.

• dan_waterworth: JRuby doesn't have the same problem, but Ruby 1.9 does.

Answer 2

Well, to scale, you need reasonable performance per line of code, right? I'm not talking C++ levels, but ... check out

http://dada.perl.it/shootout/index.html

for example on heapsort

But hey, Ruby is faster than vbscript!

• Justin: For those wondering, Red = CPU, Green = Memory.
• James: 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?
• dan_waterworth: Your mixing up scalability with performance; scalability is ability to increase the performance by throwing hardware at the problem.
• quanticle: My question is, what the heck is up with vpascal?
• mipadi: That's Ruby 1.6.7, which is more than a little outdated.

Answer 3

I think it was because Twitter was driven by Ruby on Rails and around mars-may 2008 they had some significant downtimes which started the meme

• Mahmoud Hossam: They had to switch to scala because of that, too.
• alternative: @Mahmoud Hossam didn't they only swap out performance critical parts to scala and leave the rest as Rails?
• Mahmoud Hossam: @mathepic I think the UI parts are still written in Rails, check their github for more details.

Answer 4

As mentioned, there were several "hot" ror startups that suffered issues scaling. I believe that's where the issue primarily came from.

However, there's been performance issues with ruby/ror in the history prior to those meltdowns.

See: Ruby interpreter leaking memory on long running processes:

http://groups.google.com/group/god-rb/browse_thread/thread/01cca2b7c4a581c2

http://engineering.twitter.com/2011/03/building-faster-ruby-garbage-collector.html

DHH's "rails myths" which documents 400 restarts per day:

http://www.loudthinking.com/posts/31-myth-2-rails-is-expected-to-crash-400-timesday

And of course the infamous rails is a ghetto rant from Zed Shaw.

Answer 5

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.

• Wayne Molina: 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).