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 special enough to be seriously considered for a plethora of projects and needs.


It’s possible that nobody would even know about 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 payed 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’. 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. Nohting 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.

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, this is a debate for another time, and admittedly, Ruby misses out on some features that other languages have (Lisp hmm, hmm). But 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 trough the 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 Ruby, this pragmatism produces elegant solutions and encourages/inspires the 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 nextdoor 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:

class User < ActiveRecord::Base
  devise :database_authenticatable, :registerable

  validates_numericality_of :years_of_experience, 
                            :allow_blank => true

  acts_as_taggable_on :certificates, :expertise_kinds

  validates_presence_of :first_name, :last_name, :email

  has_many :translations

  has_attached_file :avatar, :styles => {:small => "240x240>"}
  has_attached_file :cv

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.


Rails has an army of committers that make sure it stays in tip-top condition. Many projects simmer down with age, yet with Rails, sparks still fly when decisions need to be made. It feels like the maintainers (still) truly care.

Many projects simmer down with age, yet with Rails, sparks still fly when decisions need to be made.

Underneath Rails itself, as a cherry on top, stands Ruby with its formidable package manager, RubyGems, comparable to CPAN in terms of number of packages–and considering CPAN’s age, that claim is (to put it mildly) very impressive. Rails had a brief derail when it tried to make its own “Rails plugins”. Fortunately, this did not stick, so RubyGems remains the unified, superb source for code programmed by very bright individuals.

The synergy between a cool language, pragmatic web framework, and superb community gives Rails a result much better than the sum of its parts.


Rails has been around the block. In a hipster kind of way, it’s not even that cool anymore. This is good thing when it comes to choosing a technology stack: you want something proven. And Rails is just that. We recently wrote a piece talking about the wide variety of Ruby interpreters and runtimes that are now available.


I know, I know. As an IT professional, I should really value ‘serious’ things and ignore the ‘glitter’. It may seem shallow, but lets face it:

  1. Compared to the competition, the Rails site looks good.
  2. Rails’s first screen cast, back in the day, was simply breath taking. It might not look that impressive today, but remember that the only reason we all know about Java is that everybody was so fired up about possibility of running a Java Applet in the browser. This turned out not to be that important after all, but still, this put Java on the radar. Similarly, this 15-minute blog engine screencast was a huge hit that excited a lot of people.

This isn’t even about vanity; it’s about engaging as many smart people as you can to put water into the mill. When frameworks are considered, the best place to be is in the crowd. Choosing a framework that these smart people are focusing on simply means that a lot more ground is already covered for you. And this brings me to my next point.

(Not) Reinventing the Wheel

I have a soft spot for tiny frameworks. I like when I can understand what a particular framework is doing and why. In this sense, Rails is somewhat bloated, and even overwhelming at times.

The dilemma here: how many times do you want to write the same stuff over and over again? Some of it can be rewritten better I am sure, but it takes time–a lot of time. The more you allow Rails to do for you, the less you have to worry about re-writing or re-implementing your functionality.

Rails is (as they say) ‘batteries included’. This is not a good thing if you are keen on sparsity or if you feel the need to have extensive knowledge of how everything works. In practice, if you let go of your fears, it does seem to work. Rails has reasonable defaults for almost everything you need and is modular enough to avoid cornering you into a tight spot.


Rails is suitable for both state-of-the-art public websites that compete with Single Page JavaScript applications, and complex enterprise core system applications that usually look a bit ‘uglier’ (with a more generic, lower fidelity UI), but compensate this blemish with a ton of complicated business rules and logic. It’s versalite, able to compete with both the sleek and the powerful.

For most of common problems, Rails has a component at your disposal almost right out-of-the-box with documentation that is consistently above average (somehow, the Rails core team persuaded contributers that writing documentation is cool (even though we all know it’s not), leading to well written, concise and time-saving docs).

When you put aside unicorns and Friday hugs, you end up with a mighty framework that you can be used both for your future game changer and your next middle-of-the-road business site. And with your pool of top-of-the-line gems, you have at your finger tips an arsenal that implements some of the brightest ideas in computer programming. With no fuss.

Looking to hire top engineers? Check out Toptal's Ruby on Rails developers!
Editor's note: want posts just like this delivered straight to your inbox? Subscribe below to receive our latest engineering articles.
Subscribe to our engineering blog for the latest tips


I still like Rails, but I think projects like Rails-Api are a big step in the right direction for where modern web apps need to go and where Rails should be moving towards. Fears over monkey-patching are very minor concerns with Ruby; in practice its not likely to ever hurt you.
John Ward
Before I finish reading this article I just wanted to say that you're explanation of monkey patching is the first time I actually understood what people meant by it. Usually it's just assumed everyone knows what "monkey patch" means. So thanks for that.
Brad Garland
Great article - articulates so much of why I'm using Rails (after nearly 3 decades of programming). Thanks!
Excellent article. Sums up my experience with Ruby and Rails as well. Feel the happiness. I'm amazed to still find developers that try to fight the flow that Ruby and Rails gives offers. Its like they're trying to make their old practices in other languages fit into this pragmatic environment. Just an observation...
Yes. Why i love Ruby on Rails Rails is - It's powerful framework that can help you become more productive and confident, when working on complex projects.
brian piercy
Loved this article. Great job.
Philippe Van Eerdenbrugghe
The problem with the name "monkey patching" is that's completely irrelevant with what it is . It used to be called "guerilla patching" (which does make a lot of sense because those patches engage in battle with each other) and then it became successively "gorilla patching" and "monkey patching" which does not have any meaning :(
I'll probably start learning ROR anytime soon. It looks like the ultimate solution :)
Carlos Barros
groovy is much better than this shit of ruby on rails.
Leo Rosi
I would like to know HOW dhh, who considers himself a _sowftare writer_ and not an engineer, at the age of 25 (~) was able to develop and have the vision of RoR instead of all the _geniuses_ with 20+ yrs of experience, PHd's etc, out in the computer science field?? What did he see and conjure up that NO ONE else could? Total mystery to me...
Well that's exactly what mister Heinheimer or however you spell it was trying to say - that Rails and web development in general isn't engineering , and that's why a 25 year old could contribute to it or even found it . BTW many PHD's or geniuses don't really care about web frameworks or even programming in general , they're happy doing their thing . IQ or degrees really don't have a lot to do with taking initiatives. I can think of many more examples of amazing software projects that were written by 'non engineers' like Bill Gates , Mark Zuckerberg etc etc .
Leo Rosi
Agreed. But DHH used a lot of academic work (Fowler et al.) i.e. Patterns, etc to build the framework and Ruby made it easy. But one still has to wonder why, PhD/Guru/Degree or not, how out of millions of dev's out there, no one saw to use Design Patterns with Ruby. DHH did fill he requirement to build out tools that made life easier with passion and conviction. Good for him.
Yep , I agree . It can be said about so many things though , with hindsight . Why did Microsoft or Apple not think about building a social network and instead a 19 year old (talented as he may be) built it in one month in his room? You know - passion , conviction and maybe some luck never hurt :)
comments powered by Disqus
Subscribe to Engineering Articles by Email
Trending articles
Relevant technologies