KillerPHP Blog

Ruby on Rails – a paper dragon?

May 25, 2008


I was going to start this off with some analogy on how Ruby is like dating some ‘hottie’ that turns out to be crazy .. but I just couldn’t make it work …

When Ruby on Rails started to gain some momentum a year or so ago, I decided to take another look at the Ruby language itself along with the Rails web framework.

ruby on rails logo

Before I get to the heart of this article, I have to tell you that I love the elegance of the language … it is fun to use.

But, being a nerd who’s has experienced disappointment in promising new technologies in the past, I decided to dig a little deeper into Ruby and Ruby on Rails before committing to use it in real projects. I did my research … and I’m glad I went with PHP instead.

… Let me just say that this Twitter news, only reinforces my own thinking from a year and a half ago.

Why did Twitter decide to move away from Ruby and Ruby on Rails?

Well according to TechCrunch, the boys at Twitter found that Ruby could not be made to scale.


Apparently this Techcrunch report was later refuted by the Twitter people. Nonetheless, the point of this article still holds true.

I’ve also found comments from a Twitter developer (Alex Payne) talking about how slow the Ruby language is:

“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. “

Even the creator of Ruby (Matz) has his beefs with Ruby

When I heard about the critical comments made by the creator of Ruby about the language … it made me think twice about jumping in.

Always look at what’s going on ‘under-the-hood’

So, when I decided to move forward with a new web application, my first decision to make was the technology stack I was going to use. I was considering:

  • PHP
  • Ruby
  • Java with JSP and Servlets

… I had to at least consider Java since I’ve done a lot of my work in Java in the past.

Quickly though, it came down to PHP or Ruby with Ruby on Rails. Ruby was the hot new language and my little team really wanted to jump into it .. and I must admit, so did I.

But experience prevailed, and I decide to take a deeper look at Ruby (and Ruby on Rails) before I would commit myself.

… I found some major holes.

The problem with Ruby and Rails

I don’t want to get into to micro-nerd details, but at the time, I found that there were things missing in the core Ruby language, things that developers had to fall back to C solve! This was something I did not want to have to deal with.

Another major hole (and this was the deal breaker for me,) was that Ruby and web server integration sucked. It sucked hard. You had to jump through hoops to get Ruby web hosting working.

One reason I moved away from Java web application development, was because of the problems related to Java web hosting. Though I know Java server setup reasonably well, PHP is so freakin easy by comparison!

Anyway, Ruby web server integration makes the Java thing seem trivial.

Ruby reboot

Beyond all that, you’d here stories (with Ruby and Ruby on Rails) of the web server having to be rebooted several times a day! This is not at all acceptable in any situation. That alone should be enough for any self-respecting developer to want to stay away from a technology.

The above reboot problem is like buying a boat that continuously springs leaks. Who wants to have to bail water all day … especially when you’re out there on the water.

Anyway, I made the choice for PHP because it was fast, could do everything I wanted without having to write C code, and was proven.

As told one of my assistants:

I don’t want to spend months developing an application, and then find that the underlying core can’t support the load. Or … that we find that we have to reboot the web server ten times a day!

… If I wanted that, I would go back to classic ASP!



I haven’t looked at Ruby and Rails since that time, but I am sure things have progressed. That said, this Twitter news is just further evidence that the Ruby web stack stills needs work … work on the very heart of things Ruby.

It also shows that you should never jump into something until it is really well vetted.

Some related links:

The complete interview with the Twitter developer Alex Payne.

CNET on Twitter’s Ruby move.


Stefan Mischook