Meditations on programming, startups, and technology
New Relic

On Ruby and Rails Criticism

If there is one thing that politics teaches us, it is that humans have different views on how to approach and solve problems. In politics no party has the solution for all problems that affect society. Some ideas are objectively more promising than others and have a track record of being implemented with success, greatly benefiting the general population. But typically it’s not possible to state that party X offers the perfect solution for each problem, nor that any single ideology is the panacea for society. Granted that this holds true, the humanist imprint of modern society and centuries of history show us that an ideology like democracy appears to be a much better choice for most people than, say, a totalitarian regime where communism or fascism is in power.

In the programming world things are not that different after all. There are more “liberal” philosophies such as dynamic typing, Open Source, and Agile development – just to name a few. And more “conservative” ones like static typing, proprietary software, software patents, and languages entirely promoted by big corporations. Just like in politics, none of us holds the absolute truth. It’s a matter of applying the more appropriate philosophies (or in practice, methods and tools) to the art of solving complex software development tasks and problems.

Warren Henning wrote an article titled If Ruby is so great and opportunely filed it in the “Politics” category. He asks a few rhetorical questions – nothing terribly new to be fair – in order to somehow question the value of Ruby. Articles like that always cause me to smile, and I’m often tempted to just move on. But I feel compelled to use it as inspiration for a broader topic, the handling of criticism in the Ruby and Ruby on Rails communities.

The Ruby and Ruby on Rails communities have a lot of passion. We love our language, created by a very cool guy (and maestro of humbleness) in Japan. We love our framework authored by a Danish GAP model :-P, and we really enjoy the spirit in the community which grants refugee status to all PHP and Java developers out there. We have the best non-paid marketing department in the world. We started the revolution which is powering most of the new social websites out there. All these points may cause some people to consider us Ruby and Rails developers as being “religious” about our tools of choice. Religious as I intend it, implies a dogmatic acceptance of a supposed truth. A religious attitude can be seen as blind acceptance without questioning, and Ruby and Rails developers are definitely not “religious” according to this perspective.

Most of us have experimented a lot with other languages and technologies before declaring that we love programming in Ruby, and quite a few of us don’t merely settle and continue to explore the world of possibilities offered up by the software development field. It may sound pretentious, but most Ruby developers know what they’re talking about and are just “passionate” about it, not “religious”.

A passionate community is emotionally easy to attack and may produce inopportune responses in defense of whatever has been questioned. Over the past three years I’ve heard a few bad things about Ruby and I’ve seen all sorts of responses, which in some cases were simply overreactions. After a while you start always hearing the same complaints or excuses for not adopting Ruby or Rails. My bottom line is: let me show you something cool, but feel free to use whatever you like. I think that it’s important to promote valuable technical solutions, languages and tools for software problems; but the acceptance of these is not a passive process. We can encourage and show the benefits of a given technology, but we can’t force it down the throats of developers whose primary language preference is different than ours.

Sometimes the accusations towards Ruby or Rails are just ridiculous and are factually inaccurate. It is important that as a community we debunk these myths and unjustified criticisms. But it’s just as wrong to react with denial towards genuine criticism. For example if a blog states for the nth time that the Ruby interpreter is slow, there is no point in saying that’s not true, and that the benchmarks on the language shootout are bogus. Sure they may be considered worthless or not too representative of real world performance by some, but let’s be honest, we know that Ruby is slower than many other languages, why deny it? I’ve no problem with recognizing that Haskell is much faster than Python and that Python is faster than Ruby in most scenarios. There is nothing to hide or get upset about; Ruby is a wonderfully designed language whose main implementation is currently suboptimal.

Generally speaking, Ruby’s shortcomings aren’t sufficient enough grounds to discredit the language as a whole. Pointing this out in an argument is a better strategy than denying the problem a priori. As a matter of fact, I find Ruby to be fast enough for most tasks (on modern architectures), while still recognizing that an equivalent program in C would most likely be much faster. An even better road to take would be to provide examples of how computationally complex problems can be dealt with efficiently in Ruby, highlighting the best practices and the existing workarounds to deal with Ruby’s current weaker points.

My favorite approach is the one taken by brilliant people like Ola Bini and Koichi Sasada, which provides concrete answers to Ruby’s main criticism by working on optimizing Ruby (at this point you can consider it a language with multiple implementations). We should listen carefully to valid criticisms because they are a reminder of where we should focus our attention in order to improve what is an already capable language. With the expansion of the Ruby and Ruby on Rails communities, I’d love to see a trend towards the adoption of a compromise between the excellent marketing of DHH, and the humble and objective nature of Matz (it’d be dangerous if you got it the other way around ;-)).

The short post “If Ruby is so great” is not conceptually far from a hypothetical and rhetorical post entitled, “If Democracy is so great”, in which the validity of democracy as a political basis for society is questioned. In such a post one could point out the defects, drawbacks or even limits of democracy, but democracy wouldn’t be any less important and valuable. I sincerely believe that democracy is a great achievement for humanity and the cornerstone of a more equal and fair society, but there is no implication that it’s perfect and that it’s the final solution for all of the world’s problems. Ruby, in the field of general purpose programming, and Rails in the Web development arena, are no different.

If you enjoyed this post, then make sure you subscribe to my Newsletter and/or Feed.

receive my posts by email

22 Responses to “On Ruby and Rails Criticism”

  1. Lawrence Oluyede says:

    great post :-)

  2. Vinni Pyx says:

    good post, but I really doubt that you’ve a deep knowledge/understanding about things like communism, fascism and democracy… Take a look at:

  3. Hi Vinni, I’ve actually studied the subject matter quite a bit and read many books about both communism, fascism and related historical literature. I believe I have a fair understanding of it but my post was not meant to be an in-depth analysis of democracy.

    Thanks for your comment,

  4. kahfei says:

    Great post, Antonio.
    I totally agree with you there, especially after all the negativity generated towards Ruby and Rails from the Twitter incident.
    Be passionate, yes. But I think to be religiously attached to any programming language/framework, is always dangerous. Programming language is just tools. Like real languages, you can’t really say that English is better than Japanese or French is better than Deutsch. They are just, different .

  5. RR says:

    Excellent post. I agree with everything you’ve stated: so let’s take the criticism and move ahead in addressing areas of weakness and grow the language (or Rails, or frame-work-of-your-choice) to improve upon known criticisms. Indeed the very principle of community driven development is to work together for some agreed-upon harmonious purpose. Negative feedback is once mechanism of encouraging challenges for positive growth.

  6. P. Griffin says:

    This is one of the finest articles I’ve read in a long time. Well done.

  7. AkH says:

    In fact french is better than german !!

    Un francais/Ein Franzosich/A french

    just kidding 😉

  8. Adi Azar says:

    Well said my friend! I am Java developer and I learned RoR recently, I am quite amazed.

    We are now building the site which will receive highest traffic among all RoR sites.


  9. Adi Azar says:

    I forgot to say, the site was J2EE. We rewrote it using RoR from scratch. It was 160k lines, it became 11K lines. We are releasing it soon my friend.


  10. JR says:

    your point on how “others” see at RoR people sounds familiar… Being a mac user I have to read/hear once and again about how religious we are, just because we happen to enjoy the technology we use…

  11. Isaac Gouy says:

    “… wrong to react with denial towards genuine criticism … the Ruby interpreter is slow, there is no point in saying that’s not true, and that the benchmarks on the language shootout are bogus. Sure they are not accurate and …”

    What do you mean “they are not accurate”?

    (Seems like exactly the kind of blanket denial that the rest of your article speaks against.)

    A more positive approach to the benchmarks game could include contributing programs that work with YARV.

  12. jon perez says:

    “We love our framework authored by a Danish GAP model, and we really enjoy the spirit in the community which grants refugee status to all PHP and Java developers out there”

    David Heinemeir is NOT a GAP model, he is just supposed to look like one… although I’m not surprised why a Ruby advocate would make such careless statements. This is typical of the way Ruby is hyped. Image counts, the truth be damned. I have to admit, it does seem to work though, at least in the short run.

  13. @Isaac

    “They are not accurate” meaning that they are somewhat limited in their scope, because complex real life programs may perform differently, based for example on the efficiency of the libraries used. They still provide a numerical indicator of Ruby slowness and I’m not denying this at all. I am the author of a Ruby shootout that can be consider just as much “inaccurate” from this perspective, but which still shows that Yarv is much faster than Ruby’s main interpreter.

    @ Jon Perez

    Relax man, it’s a joke about Wired’s statement. :) DHH is a programmer, not a model, everyone knows that. There is no need to read too much into it, nor to stereotype Ruby advocates as producers of “careless statements”.

  14. Isaac Gouy says:

    * “somewhat limited in their scope”

    Antonio, without wishing to be pedantic, that isn’t even remotely like the meaning of accurate:

    careful, precise; lacking errors

  15. Isaac I see what you mean. I wrote “They are not accurate” but I meant “They are not an accurate representation of real world performance”.

  16. Isaac Gouy says:

    It would be nice if you could correct that before it gets echo’ed around the blogosphere :-)

    Someone more argumentative than I should ask you to demonstrate that they are not “an accurate representation of real world performance” 😉

  17. Isaac, I rephrased it in order to be more… accurate. 😀

  18. Isaac Gouy says:

    Thank you, I think that gives a more … accurate, impression of the malign comments some people have made 😉

  19. senior app janitor says:

    It’s ironic most of the guys criticizing are going to continue to churn out the over-engineered bloated, down-right ugly pretentious crap to complete the rest of our miserable maintenance drop-everything-and-do some compile and re-jar and redeploy out of your hair-brained CMS for a tiny freaking tweak, yeah they’ll continue and they’ll continue to make 50K more than PHP/Rails/Python programmers.

  20. miguel says:

    Scalability is simply damn hard to achieve.

    I don’t think the interpreter is the problem. It think the problem lies in Rails. Rails was designed to take away the sweat from programming. Easy, fast. At the cost of what? (anybody here believes in free lunch?) My favourite metaphor: rails is like trying to race formula1 with a nice automatic Cadillac, you will have a good time, but loose the fun when you get overturned.

    Don’t get me wrong: nothing against Rails – for small, quick things, no better way to make customers happy. Enter real hard life, where 600 requests per second was your pride of yesterday, you suddenly need to understand how Rails has been solving (hiding) problems for you and simply find better solutions.

  21. morissen3k8 says:

    Can’t the Ruby interpreter be optimized to increase speed? JAVA in the early days was also slow but was improved upon and subsequent revisions have optimized it to a point where it isn’t slow. So in other words, can’t the Ruby interpreter be rewritten for greater speed just like we have so many versions of X86 with faster processors each generation?

  22. […] it’s been out it has managed to get faster with each new version. A very good article is “On Ruby on Rails Criticism” is a very good article and should be read. He has a very good discussion based on how communities […]

  23. says:

    I agree completely with what you say and I have to admit that people should stop complaining about the tools. A good programmer should be able to code in anything and still make the end product good. It is not the language that makes the product it is the years of software engineering skills that the developer has built up. At the end of the day unless it is an official bug stop blaming the tools for the problems.

    I have recently wrote an article that might be an interesting read to you after having read this (

  24. […] slower than Haskall, slower than Python, slower than PHP, slower than Perl. Even proponents of it admit that Ruby is slow. In order to get around the slowness, people have to use FastCGI, or […]

Leave a Reply

I sincerely welcome and appreciate your comments, whether in agreement or dissenting with my article. However, trolling will not be tolerated. Comments are automatically closed 15 days after the publication of each article.

Copyright © 2005-2014 Antonio Cangiano. All rights reserved.