Sometimes I hear people complaining about their clients, saying that they insist on using Rails, that they’ve had too much Kool Aid. If they’re recruiters, they almost feel sick in the stomach about having to find yet another Ruby on Rails ‘primadona’ developer. Then they pull out something similar to this amazingly ignorant comparison between Git and PHP to prove their point. “They don’t even know what they’re asking for,” they say.

For us as programmers, sometimes it does indeed seem like our clients don’t have a clue. We love to exaggerate cases like this. When you think a bit about it, it does not seem right to think that a person that is giving me money to build things is somehow limited and ‘just doesn’t get it’. In fact, I believe that most clients know their options just fine and yet they still decide to go with Rails.

I’ll try to explain what, in my opinion, makes Rails beneficial enough to be seriously considered for a plethora of projects and needs. - Niels Siskens • Parrolabs Founder

Benefits of Ruby

It’s possible that nobody would even know about the benefits of Ruby if it weren’t for Rails itself. Some people like to belittle Ruby by saying that it’s “so easy for Ruby” with its “knight in shining armour called Rails” and that without Rails, “Ruby would be irrelevant”. I can’t say for sure whether or not that’s true, but I do know that it would be a huge shame if the world missed out on such a superb language. The fact is: the author of Rails picked Ruby deliberately, and his ‘wild’ bet paid off with huge interest. What he saw back then, many others can see today. Ruby somehow enables programmers in a special kind of way that is so hard to explain to the ‘unwashed masses’. So, why use Ruby on Rails? Ruby makes programmers happy, as advertised.

While most developers agree that Ruby is handy, some see it as too much so. They worry about what might happen with all the freedoms that Ruby allows, all the potential for misuse. Let me illustrate with some monkey patching:

#=> 1

class String
  def to_i
    raise 'foobar'

#=> RuntimeError: foobar

It’s that easy: with just five lines of code, we’ve taken an existing class and overridden its behavior. Nothing is sacred–not even a String. This particular error would be easy to spot, but things can get much more sinister:

class String
  def to_i
    self.to_f - 1.13

#=> 0.8700000000000001

Just like that, we’ve introduced an error into the String class that could be wrapped into and obscured by layer upon layer of complexity.

So, you might be thinking: Can everybody and their mother mess up my precious application? While this behavior indeed looks scary–it’s really not. In five years of using Ruby, I’ve had exactly zero problems with this behavior. It may seem counterintuitive, but then again, so is driving cars at 60 MPH in opposite directions separated only by a thin white line in the middle of the road. In practice, both work remarkably well.

It may seem counterintuitive, but then again, so is driving cars at 60 MPH in opposite directions separated only by a thin white line in the middle of the road. In practice, both work remarkably well.

Another benefit is that Ruby is a versatile tool. As such, it has sharp, knife-like edges. I like to think that grown-ups can handle knives just fine–child-proofing is for, well, children (Tweet). And being treated like a child in IT leaves you a victim of Paul Graham’s Blub paradox: you think you are better off without certain features that you don’t understand or that someone told you are too dangerous. Of course, today we are asking “why use Ruby on Rails”; thus, this is a debate for another time. Admittedly, Ruby misses out on some features that other languages have (Lisp hmm, hmm). All-in-all, Ruby is close to the top of the ‘language power continuum’.

My first few years with Ruby were humbling. I learned so much just from reading through others’ code. Sometimes, I was amazed; sometimes, I was mad; but eventually, this knowledge enabled me to communicate with my computer much more effectively than before. I almost feel sorry for some other ‘red tape’ languages that make you jump through hoops just for the sake of jumping through them, all while telling you “I am just doing what’s best for you, it’s for your own good!”


There is a deep respect for pragmatism knitted into Rails’s DNA at the lowest possible level. In combination with the benefits of Ruby, this pragmatism produces elegant solutions and encourages/inspires the Ruby on Rails development community to do the same. Pragmatism is often advertised as a tent of Rails, so this claim isn’t new, but I was reminded of it’s truthfulness quite recently as a friend of mine tried to show me just how “cool” Hibernate really is. He was struggling. I could feel his pain as he was unable to set a myriad of options and configuration parameters that should have been framework defaults in the first place.

With age, my standards for artificial complexity have grown higher and higher. Considering that I started writing production code back in 1989 at age 11 (beginning with a project for my next door neighbor in Clipper Summer ‘87), I have close to zero tolerance for unnecessary complications. And Rails scores really high in that department. It’s more than just ‘convention over configuration’; I am talking about the whole pragmatic mindset that is highly valued within and permeates through the Rails community.


Rails is as close to English as it gets (unless you are using COBOL). It uses what’s known as an internal DSL, extending Ruby with its own semantics. Constructing a DSL is always dangerous as you are effectively developing a new language. Because it is internal, you don’t need to use an external parser, but in a sense it feels like a new language. The Rails team struck a good balance with its DSL, using it where it makes sense and only seldom overdoing it, demonstrating excellent self-control. I think that any programmer, regardless of Rails experience, (and even some non-programmers) could understand this:

In fact, if you’re not familiar with Ruby, this might look odd–it’s almost as if it’s not a programming language. Once you realize that it’s just method calls without parentheses, you are good to go. Still, the Rails DSL feels like it is this special language for describing requirements when in fact it is just smart naming and inherent usage of Ruby’s excellent syntax.