Busting Ruby on Rails Myths

I am working on a project for a client of the IT company I work for and I am convinced that Rails is perfect for it. I have a meeting in the next day or so, where I am afraid I am going to get bombarded with "why Rails?" type questions, and no doubt, a whole bunch of rhetoric like "Rails doesn't scale", "Rails is just a CMS" and the thousand other myths people seem to have about Ruby on Rails.

We have all seem the arguments about how Rails doesn’t scale, it’s hard to deploy开发者_运维知识库 or that it will explode in your hands at any given moment. For those of us that use Rails on a daily basis, we know that just like any other language or framework. It seems like there is a lot of misinformation about RoR and often Rails gets a bad wrap. To help me with this meeting, I was hoping to compile a list of myths - perhaps one myth per answer - and we can vote for the myths we've heard before - to eliminate the Fear, Uncertainty and Doubt that often clouds the truth about Rails.

After some googling I found this blog post which is exactly the kind of thing I'd like to collate here. As David Heinemeier Hansson says in the post:

So I thought it would be about time to set the record straight on a number of unfounded fears, uncertainties, and doubts. I'll be going through these myths one at the time and showing you exactly why they're just not true.

This is not really to convince you that you should be using Rails. Only you can make that choice. But to give you the facts so you can make your own informed decision. One that isn't founded in the many myths floating around.

Let's Clarify!

Myth: "Ruby on Rails doesn't scale"

Bust: That is not a specific, answerable question. Please clarify.

Saying that whatever-technology "doesn't scale" sounds very professional and very enterprisey - but it's not a clear question. It's just a lazy way of dismissing the unknown/unproven I'd ask for clarification:

"What precisely do you mean by 'scale'? and how do you measure it at the moment?"

It could mean:

• Maximum user sessions
• Average response time given load
• Throughput of given concurrent scenarios per server in a fixed time.
• ... difficulties organising the project so a large team of developers could work on it.

There are lots of ways of dealing with "scale" but until you know which one you're dealing with it's not always obvious what to do about it.

There are loads of ruby-based solutions, including

• caching fragments of HTML
• sharding the application across multiple databases
• pre-computing work that's shared between users
• pushing lots of view-rendering work off into AJAX/Javascript land so it happens on the client
• using a front-end web server more efficiently
• just use more hardware (i.e. developer time is expensive & hardware prices fall) but this approach depends on a shallow rate of growth in demand
• doing less interactively and having more batch work
• doing only part of the work in ruby - e.g. existing legacy backend+rails frontend, or maybe the transactions through a functional programming system+rails frontend

If the challenger can't come up with a specific meaning of "scale" then it isn't a valid concern.

However if the challenger does come up with something specific and measurable, then I'd use a timeboxed, spike solution ( http://c2.com/xp/SpikeSolution.html ) to come back with some numbers - and possibly a few options on how to do it.

Make the argument from the only perspective the client understands, money!

Show how long you think it will take to make in Java, JSP, or whichever is their current technology, together with the pros and cons, such as easier to obtain developers. Then, state the timescales in Ruby, which for sure will be lower development costs, but also at a cost of the admins having to deploy a different system, possibly harder to recruit staff who know Rails, etc. Its their money, so give them the facts and let them make the decision.

In response to the specific criticisms a company could have against Ruby on Rails compared to their own systems there are many reasons a company can give, some of them not specific to Ruby or Rails, such as they already have many Java develops in house, or existing infrastructure written in Java, which will always be easier to use with a same language system such as Java. Anyway, to answer your specific points:

1) Why Rails? Simple, Rails is "designed " for building web sites, and does an efficient job. Find some statistics to back you up (I'm not saying the statistics in the link are accurate but numbers will always impress a client)

http://www.theserverside.com/news/thread.tss?thread_id=33120

2) Rails doesn't scale

http://trak3r.blogspot.com/2008/03/rails-doesnt-scale.html

3) Rails is just a CMS? If they are building a CMS then recommend Drupal, not Rails

I guess you will have to think on your feet when you answer your clients questions, and they will want someone who understand other frameworks apart from just Rails, kind of like using the right tool for the right job

Myth: Rails is not mature enough to have the plethora of hardened open source libraries built around it that one needs to pull off a large scale project quickly and reliably.

Bust: In fact, there are a ton of gems and plugins available to the RoR community, many of which have been tried and found true by the active community. Not only are the resources there, but they are simple to manage with 'gem' and Rails' built-in plugin architecture. Worst case scenario: you can't find that perfect gem or plugin. In that case you can easily write your own or borrow from the Java world if you use JRuby.

Myth: it is hard to hire a good Ruby on Rails programmer.

(Actually, I can't bust it, that's just an idea of a potential myth. Who can, please, edit this one or create another answer)