Since Ruby isn't a scalable back end solution

see this excerpt from the rails tutorial by Michael Hartl on rails scalability.

"Before moving on with the rest of the introduction, I’d like to take a moment to address the one issue that dogged the Rails framework the most in its early days: the supposed inability of Rails to “scale”—i.e., to handle large amounts of traffic. Part of this issue relied on a misconception; you scale a site, not a framework, and Rails, as awesome as it is, is only a framework. So the real question should have been, “Can a site built with Rails scale?” In any case, the question has now been definitively answered in the affirmative: some of the most heavily trafficked sites in the world use Rails. Actually doing the scaling is beyond the scope of just Rails, but rest assured that if your application ever needs to handle the load of Hulu or the Yellow Pages, Rails won’t stop you from taking over the world."

This is a pretty good article covering the misconceptions surrounded by attributing lack of scalability to language or framework. Above explanation is also good, but if you're interested in a more in-depth discussion on popular sites and scalability, it's a good read too!

Just to add to Stones answer with some info on how you could scale Ruby, Ruby could be scaled using multiple instances of Ruby mirroring the same files connecting to say multiple databases e.g. a mysql cluster. In theory to break it down any language can be scaled as when you look at a Network there are 7 Layers. Ruby would rest on Layer 7 so you could either scale by a software based load balancer on Layer 7 e.g. an instance that takes visitors and redirects them based on the load of other instances or via a hardware based load balancer which could direct traffic based on bandwidth, number of IP's connection and any other number of network variables. Typically you would locate a hardware load balancer on Layer 3(The routing layer) of a network to best route traffic but it can be done in any number of ways in theory on any network layer. Its simply down to personal preference and experience.

Hope this helps

I'll just throw in my quick word on this as well. The company I work for built our entire platform on Rails and we handle hundreds of thousands of transactions on a daily basis. There has been some complaint of Rails being a "slow" framework, but all in all with the right optimization and some experience with Rails it is a great tool.

This is a super interesting topic to me, as I'm primarily focused on scaling and automating Treehouse. Most of the issues we've seen that people would typically attribute to Ruby/Rails not scaling are problems that can be solved by optimizing database queries (and/or adding indexes) or adding additional caching. So far Ruby is doing the job for us.

I'll second this. rails scales just fine, though it's more memory-hungry than some alternatives (happily ram is pretty cheap these days). I've personally worked on teams that scaled Rails apps to > 100K RPM, and the bottlenecks were never Rails itself, but rather the ecosystem around rails, the total application infrastructure comes into play.

Bypassing rails for requests that don't need to pass through the app (google "unicorn nginx try_files") and using the appropriate rack http server for your workload automatically takes care of 80% of scaling the application. after that you're just scaling horizontally behind a load balancer, and caching what you can (Dalli + Memcache is a nice mix here), which can go on well past the point where you're going to start running into the need to start scaling other system components like your database server or your queueing system.

I'm sorry for being a troll guys. Perhaps we should make a course?

Nathan Williams At an internship where they ran a Java Struts 1 web application in a WebLogic application server the software engineers spent 70% of their time trying to reduce memory usage because it was always about to run out. I remember one of the "optimizations" they came up with to shave what little free they could was to replace primitive boolean instance variables with the TRUE/FALSE constants from the Boolean class instead. Which doesn't really make much sense to me but I have a lack of knowledge in regards to the stack and heap.

Do Ruby web applications require more regression testing before putting a new build on production? I ask in regards to what I understand about Java being half or semi-compiled and being able to catch more errors at run-time as opposed to (assuming it is an interpreted language) Ruby web development?

hey christopher,

i can't really say whether rails requires 'more' or 'less'. while i've often deployed java apps to production (elasticsearch, logstash, solr...), i've not worked in a shop producing their own java applications.

i can say that the ruby/rails community seems fully aware of the importance of (unit/integration/regression) testing, and good test coverage is a point of pride for a lot of developers.