What are the Benefits of Ruby on Rails? After Two Decades of Programming, I Use Rails

View all articles

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.

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

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:

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 and want people to use Ruby on Rails and understand its benefits.

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.


Ask yourself again, why use Ruby on Rails? 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. Its benefit is that it is versatile and 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.

About the author

Krešimir Bojčić, Croatia
member since January 16, 2013
Krešimir is passionate about building great applications while minimizing the artificial complexity that often creeps into projects. He has 10+ years of experience in building, optimizing, and delivering a "perfect" user experience. [click to continue...]
Hiring? Meet the Top 10 Freelance Ruby on Rails Developers for Hire in August 2017


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 :)
I read this over and over (especially by javascript framework advocates like ember.js etc) . The thing is that a good maintaing of that gem(Rails-API) and maybe some nice tutorials on using Rails as an API is enough . I don't think the whole community should put all it's efforts into that ... Rails already works as an API , it just needs some more best practices (and we'll have those when or if demand increases) and maybe a different folder structures to accomodate a javascript framework . That's really not that complicated , I don't think it will take years of work to do that . But it seems that there's a big debate on server vs client side rendering and your view of where 'modern web apps' need to go doesn't 100% correlate with what we see (e.g Twitter who ditched client side rendering to server side rendering) . It's perfectly OK to use Rails as is , and then add a respond_to for an API .
Puro Box
There is a lot of arrogance and a lot of ignorance among RoR developers. Yes, RoR brought to the table many exciting stuff that php frameworks, java frameworks, .net frameworks, didn't have back then. But now those days are gone, and amazing frameworks like laravest (php), are doing amazing stuff as well. RoR might be hipster, trendy and cool, but that does not make it superior AT ALL.
Very nice article about Ruby! Very few like these out there. I started with Ruby in 2005 and for jobs reasons ( I contract all the time) couldn't fully embrace it until recently. This year I ventured into DevOps assignment and got into Ruby once again and boy! As you mentioned it once again made me really happy as advertised!! I understand and appreciate its power even more know as I myself have matured and can appreciate what Ruby does. All this praise is without having used RoR! But I will switch soon as I have already suffered long enough with the nonsense that is Spring/Hibernate. I have used Python also for quite some time but Ruby wins hands down! It is sheer minimalist yet elegant and does not treat programmers like kids. It's very versatile and can be used almost in all environments with ease. Usually I don't comment or participate much in the blogging world but I really want to share my experience and spread the joy that is Ruby! Thanks for this nicely put blog!
Iulian Clita
Now PHP has Laravel which is absolutely amazing. As I see, Laravel is much inspired by Rails which is great.
The information shared in this article about the benefits of ruby on rails and many more are very nice and helpful.IO really enjoyed reading this article. Thanks for sharing such a nice post. <a href="http://www.cryptextechnologies.com/">Ruby on Rails Development in India</a>
Interesting man - Two Decades of Programming, you are Using Rails
I am using Wordpress with JSON-API to build "modern web apps" but it is pretty limited for this cause. Since Wordpress is most common CMS, it is great for client work where you can not choose the development environment. But for building the Apps from the Scratch I am thinking of MeteorJS vs Rails. And the question of client side rendering which is one of key factors for making apps faster is not making things easy for SEO purposes. Also routing is very important for WEB Apps and Rails seems to be doing this extremely well. I think Rails definitely seems to be a great thing to learn for web apps. A MVC approach with forgiving language as ruby seems like a great tool and since AirBnB is and Basecamp are using it it must have been proved very well. (For any of you very in love in WP there is a solution to do Rails-like routing with the http://upstatement.com/timber/ plugin).
Ruby is sloooooooooooooow
Luis Ezcurdia
In general I think that ruby and rails are mature technologies capables to build great software, and the only reason you shouldn't use it as your base technologies is because you will use extensive and complex calculations that will require concurrency, to be honest most of the business don't need a high efficiency language but the one who enables their developers to deliver fast, which is the main feature in ruby and rails.
Rayhan Ali
Also, you are wrong about client paying us. Many a times it is just an employee wasting company resource to save his arse from wrong decision. I have met few IBM ESB developers and client was bleeding deep red by buckets. I intervened in two such projects. You will not believe it was mere web service and ftp task that they were unable to finish in nearly 6 months.! I estimated less than a week with Java. Not to mention they were paying huge sums for billing rates for all these unproductive resources.! And manger was least bothered about money. He was just trying to save his job and using communication gap to hide enormous waste. So yes, person paying you may be client but not in a strict sense.
Rayhan Ali
I get fed up with programmers showing power of language with typing.! For web applications I found Perl with mason super easy, super fast and best out there. I have met few ruby on rails and it is another Ms commerce server or ejb in the making. Clients get stuck and they hire morons like IBM portal server developers to do trivial task. You didn't explain architecture or use case and that is the red flag.! I am starting my own company and last thing I want is to get stuck with moron who knows internal of IBM ESB, portal server or ruby on rails without any common sense.! Eg I can do big data analytics in Java but distributed Scala makes much more sense. I am giving specific example of business use case for Scala. Without it I would have to write boiler plate codes for managing distributed system. On the same line I am looking for business use case for ruby on rails. I am least bit interested in language syntax or that you can override some classes. I am looking for productivity.!
I think you are out of touch with non-programmers if you think any non-programmer could understand your example. I am a part-time programmer and your example is incomprehensible to me. After thinking about it for a while, it would seem to me the scope of your example is for a web application. class User < ActiveRecord::Base --- I know what a class is. I know what a user is. What does ActiveRecord::Base mean? I know what a record is in a database, and I assume an active record must mean the current record, but what is ::Base? devise :database_authenticatable, :registerable --- devise? that's an uncommon word. to create or plan something? authenticatable? That is so not a word. But okay, so there is a database that can have a user authenticated against it. Why is that important to know that it's not just a database, it's an authenticatable database? This seems like overcomplicating things. what is a registerable database? Again not a word but, okay. has_many :translations --- as opposed to has_many :dineros? when do you move from has_few to has_many? what about has_justtherightamount : goldilocks? Whatever that is talking about seems so abstract. Maybe it's so specific to what you are trying to accomplish that it loses all meaning outside of your environment. I'm not saying that Ruby or Rails is bad, I'm just pointing out that your example is not at all easy like you think it is. The whole reason I found this web site is because I was wondering why people would like Ruby? I read Ruby code and it seems complex. "typedef int (WINAPI *LPFN_CONVLEN) (ULONG, PULONG)" "_convertLengthToIpv4Mask = reinterpret_cast<LPFN_CONVLEN>(func);" ULONG, PULONG, typedef?? I thought casts were hard enough but now we have reinterpret_cast? Clearly I'm not a programmer but this reminds me of pure C code. Have a great day :)
Could be, but there are many backend applications with countless forms and huge databases that don't benefit from a separate frontend framework.
"typedef int (WINAPI *LPFN_CONVLEN) (ULONG, PULONG)" "_convertLengthToIpv4Mask = reinterpret_cast<lpfn_convlen>(func);" this isn't Ruby tho
Beatrice J. Minor
Great article, Thanks for sharing this information. RoR is a server-side web application framework which allows us to create amazing websites. It is more secure and easy to learn. To know more about Ruby on Rails you can check out this article for sure: https://goo.gl/wySXDz
Benjamin Kruger
I know I'm replying to an old comment, but... Monkey is often used to describe altering something that already works, in the form "to monkey with". E.g. My mother, who's got benign tumors in the throat, asked her doctor if it was safe to get dental work done that would require lots of x-rays. He replied, "If it was me, I certainly wouldn't monkey with it!".
Angus McIntyre
C is being used as an example of complexity. I've been programming a while and found this example retarded. It reminds me of stupid questions interviewers ask to make themselves feel better.
comments powered by Disqus
The #1 Blog for Engineers
Get the latest content first.
No spam. Just great engineering posts.
The #1 Blog for Engineers
Get the latest content first.
Thank you for subscribing!
You can edit your subscription preferences here.
Trending articles
Relevant Technologies
About the author
Krešimir Bojčić
T-SQL Developer
Krešimir is passionate about building great applications while minimizing the artificial complexity that often creeps into projects. He has 10+ years of experience in building, optimizing, and delivering a "perfect" user experience.