Ruby on Rails pain at Twitter

Josh Kenzer has posted an interview with Alex Payne, a developer for Twitter, which is one of (if not the) biggest Ruby on Rails-based web apps.

A couple of years ago, when I was getting tired of working within the confines of the Java/J2EE bubblesphere, I tried out PHP and Ruby on Rails, intended to like Rails; instead, I surprised myself by preferring PHP, an ugly hack of a language optimized for script kiddies (I’ve been using it ever since). It looks like Payne is coming to the same conclusion, as his team has ended up working to keep Twitter running despite RoR instead of because of it. Here is an excerpt:

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.

There’s lots more in Kenzer’s posting, including Payne’s claim (I don’t know enough to verify) that Rails cannot support more than one database at once, and that “Running on Rails has forced us to deal with scaling issues — issues that any growing site eventually contends with — far sooner than I think we would on another framework.”.

This entry was posted in Uncategorized and tagged . Bookmark the permalink.

1 Response to Ruby on Rails pain at Twitter

  1. Scott says:

    “instead, I surprised myself by preferring PHP, an ugly hack of a language optimized for script kiddies (I’ve been using it ever since)”

    If Apache had included server side JavaScript (the uber-script-kiddie language) support, PHP would have died on the vine. I have always been dumbfounded by the fact that Microsoft actively supports server side JavaScript (or jscript in the MS world) while the open source Apache community doesn’t (effectively) support JavaScript (Mozilla JavaScript or ECMAScript).

    JavaScript is ubiquitous (everywhere) on the client side. Wouldn’t it be nice if the same set of tools could be used on both client and server? In the Microsoft world they can be. In the Open Source world, Apache and server side JavaScript is not a viable option. Bummer.

    I use a variety of both server side and client side languages. On IIS paltforms I use JavaScript exclusively (Ok, I’ll admit to using some c# and vbscript, but I swear I’m not going over to the dark side :-). On Apache servers, I use PHP for server side scripting. Obviously that doesn’t work on the client side, so I still use JavaScript on the client side.

    Both JavaScript and PHP offer Object Oriented programming methods. For OO development PHP 5 has probably jumped ahead but JavaScript still holds its own (even though it is prototype based).

    Did I mention that VBScript works server side on IIS as well as JScript? PHP works on IIS as well (as an add-on), but why bother?

    For what it’s worth, I enjoy developing applications. JavaScript is my first choice for both client and server development in IIS environments. On Apache, I use PHP for server side programming. I do think that with PHP, the same tasks can be done more easily and with less code than with server side JavaScript. However, given the choice I would probably prefer end-to-end JavaScript rather than having to code in two different languages.

    I guess I could hope for the day when JavaScript includes PHP functionality (simplicity) or for the day when PHP is supported on the client side. On the other hand, I have real world applications that I need to develop today.

    Scott

Comments are closed.