My general issue with Ruby

Sadly, I’ve had 0 time to get further along in my first ruby project, although significant functionality is already in place (not that there’s actually that much functionality). But as I’ve been going through both Ruby and Rails, it has struck me that all the convenience it gives you must surely come at a cost in performance. Which is a fine and dandy tradeoff, but at no point do they ever make you aware that you are making that tradeoff. That is my whole issue.

It was with disturbing frequency that I’d be going through one of the books and say, that’s cool, but it sounds expensive. I would look for some mention of whether or not there was a performance cost and there never was any mention of this. It seems mildly irresponsible for them to not mention any performance risks when using many of these convenience features.

However, being a beginning ruby developer, I waived it off and pressed on. I was glad, though, to come across this interview that’s been making it’s way through the interwebbing of one of the Twitter Developers (Alex Payne) who airs his issues with Ruby and Rails scalability.

Key quotes, from my perspective:

None of these [hardware based] scaling approaches are as fun and easy as developing for Rails. All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.

It’s also worth mentioning that there shouldn’t be doubt in anybody’s mind at this point that Ruby itself is slow.

This was my suspicion all along. I don’t think it takes anything away from Ruby or Rails, they both still are excellent frameworks to develop on. The number of sites that will require the amount of scaling that Twitter requires is incredibly small in the space of all websites and many of the popular sites I see now on Rails are subscription driven sites whos traffic is proportionately small, so performance isn’t the key issue. What is important is speed of development and deployment at which Rails seems to shine.

For a site like Twitter, it’d almost make sense to view a Ruby implemenation as a prototyping system which can be scaled out in a different language altogether once a certain traffic threshold is hit. Scaling out with significant hardware is costly, difficult to manage and not fun as Alex points out. Pulling out the things that makes Rails Rails (RJS, ActiveRecord, etc..) doesn’t seem to make sense. So taking the Rails implementation as a learning experience and rewriting the whole app in another more scalable language would seem to me like a good idea. Again, the number of sites that would have to do this would be quite small, hopefully by the time this would be an issue you’ve been bought by Yahoo and have significantly more resources to throw at a complete rewrite.

And unrelated to all that, I like that he said this:

I don’t think Twitter is a replacement for blogging, just as I don’t think blogging is a replacement for journalism.

Too often when new technology comes around it is touted to replace anything that it might conceivably be in competition with, regardless of any differences between the two. It is true with blogging, with twitter, and with ruby and rails. Really the only thing it’s not true about is perl, which is great for everything, including doing your dishes and making you dinner. It’s refreshing to see a view like this from a developer of Twitter, which is in my opinion a great technology, but waaay overused and overhyped.

Apr 17th, 2007 · Comments RSS · · · · · Tags: ruby