5 reasons not to use ruby on rails
By Justin Silverton
Introduction
wikipedia defines ruby on rails as the following:
Ruby on Rails, often called RoR, or just Rails, is an open source web application framework written in Ruby that closely follows the Model-View-Controller(MVC) architecture. It strives for simplicity and allowing real-world applications to be developed in less code than other frameworks and with a minimum of configuration. The Ruby programming language allows for extensive metaprogramming, which Rails makes much use of. This results in a syntax that many of its users find to be very readable. Rails is primarily distributed through RubyGems, which is the official packaging format and distribution channel for Ruby libraries and applications.
I have worked on a couple of projects with ruby on rails and in my experience, it is not ready for large-scale applications and other languages should be considered (asp,asp.net,PHP, or perl) before taking on a project.
Here are the 5 reasons why I am not going to be using ruby on rails for my next project:
1) it’s a buzz language
As a consultant, I’ve come across many clients that only want to use ruby on rails simply because they’ve heard about it in the latest issue of their favorite tech magazine. Just because a language is the latest buzz doesn’t mean it is more powerful a better choice for the job.
2) The language is young
It was released to the public in July of 2004 (source: http://en.wikipedia.org/wiki/Ruby_on_rails#History). Many other languages have a better history and track record.
3) Poor support for IIS
Even though I personally use apache+linux or freebsd, there are still many corporations and sites running IIS. Although there are docs explaining how to configure it properly, the difficulty and lack of information leads me to believe that it is aimed at a *nix crowd.
4) creates dirty code
Here is an simple example of ruby code (it takes the factorial of a number):
if n == 0
1
else
n * fact(n-1)
end
end
This may work for small scripts and apps, but large applications with thousands of lines of code and hundreds of source files will be very difficult to manage with this type of syntax.
5) scalability
I’m not saying ruby does not scale, it’s more of a question: Does it scale? this one also ties in with #2. I have not come across any large, feature rich, and popular website or service using ruby on rails as its main powerhouse. Until I can be confident that it is indeed possible, I am going to focus my attenion on other languages.
Conclusion
I believe that you should always use the right tool for the job. Many people get caught up in the newest buzz words and languages, but aren’t looking at the overall picture. Ruby is a promising language, and works well for small scripts and utilities, but shouldn’t be used it large-scale applications until it is a proven technology.
24 Comments so far
Leave a reply
I don’t know if you consider Odeo and Basecamp as large and feature-rich website/service, but they both use Rails.
uh you missed the boat on number 2. Ruby on Rails is the framework not the language. Ruby the language was first released to the public in 1995.
“2) The language is young”
What’s young is the framework, not the language. Ruby has been around for at least ten years I think. When considering the age of RoR one should also take into account that dynamical languages allows one to develop things so much faster.
“4) creates dirty code”
There’s nothing wrong with your code sample. For more complex functions I would consider using an explicit return statement, but other than that it looks nice to me. I don’t know if your argument is that it’s impossible to have a language which makes both small scripts and large apps look nice and stay readable at the same time!? I’d say no, just look at Python.
I agree about the buzz word part. If the language or scalability troubles you maybe you should have a look at Django.
Hmm. I respectfully disagree on some of your points.
1) You’re right that most-buzzed tool isn’t always the best for the job, but sometimes it really is. Having a buzz isn’t in and of itself a reason to avoid something - a tool should be evaluated on its suitability for the job rather than dismissed out of hand.
2) Ruby on Rails is young. It is also not a language - it’s a framework. Ruby is the language that underlies the framework, and was released in 1995. PHP was first released in 1994 (I know of no frameworks that attracted anything like the numbers Rails has prior to the debut of Rails; since then a number of ‘em have sprouted up - including Cake, Symfony, and Zend’s own framework (which is still at 0.1.4 as of this comment). Java was released in 1996 (the the JDK 1.0, at least), with Hibernate coming in 2001 and Spring in 2003. Again, however, youth alone is not necessarily a problem.
3) IIS support is problematic, as is hosting more broadly. More and more hosting providers are adding Ruby and Rails support, however, so this will only improve over time. This would be a valid reason to avoid using Rails on a project - if you can’t or don’t want to change hosting providers.
4) I’m not sure why the given example is dirty. Here’s the same code in PHP:
function fact($n) {
if ($n == 0) {
return 1;
} else {
return ($n * fact($n - 1));
}
}
Certainly it could be cleaned up - eliminating multiple exit points from the function, for instance - but the PHP example suffers from the exact same problems. And of course, there’s always another way to perform such a simple calculation. Perhaps this is ‘cleaner’?
def fact(n)
f = 1
(1..n).each do |i|
f *= i
end
end
5) I’m not sure what your metric for a “large, feature rich, and popular website or service” is. 37signals’ apps have supported over 500,000 users - but the might not be classified as ‘feature-rich’, since the 37s philosophy is one of simplicity. A List Apart uses RoR and is 3343 on the Alexa traffic ratings; Penny Arcade uses it and is 1497 (for comparison: Yahoo is #1, the Washington Post is 182, comics.com is 1523, and Ford is 3920). One of the underlying philosophies of RoR is ’share nothing’, so a properly-coded Rails app’s scalability is determined more by the supporting software (e.g., the database and web server) than by Ruby or Rails itself. There’s a ton of discussion about this on the web at large for anyone who’s interested.
“uh you missed the boat on number 2. Ruby on Rails is the framework not the language. Ruby the language was first released to the public in 1995″
I am talking about ruby on rails, not ruby as as a language. Although I may have made a mistake defining ruby on rails as a language rather than a framework, it does not change my point.
“I don’t know if you consider Odeo and Basecamp as large and feature-rich website/service, but they both use Rails. ”
I’ve never seen those sites before. They do look like they are feature-rich, but those are only two examples. There are probably thousands of large website examples written in php, asp, asp.net, jsp, and perl.
” I’m not sure what your metric for a “large, feature rich, and popular website or service” is. 37signals’ apps have supported over 500,000 users - but the might not be classified as ‘feature-rich’, since the 37s philosophy is one of simplicity. A List Apart uses RoR and is 3343 on the Alexa traffic ratings; Penny Arcade uses it and is 1497 (for comparison: Yahoo is #1, the Washington Post is 182, comics.com is 1523, and Ford is 3920). One of the underlying philosophies of RoR is ’share nothing’, so a properly-coded Rails app’s scalability is determined more by the supporting software (e.g., the database and web server) than by Ruby or Rails itself. There’s a ton of discussion about this on the web at large for anyone who’s interested. ”
Very interesting. I will have to check it out.
Justin, I actually appreciate this post as most of your reasons are rock solid, and your rebutal in comment 5 is pretty solid. I am a lover of RoR, so I would like to know what is wrong with the factorial code. If it is that the lack of braces and parenthesis is hard to read, then I want to make sure you know that the parenthesis can be used, I am not certain on braces, and RoR pushes DRY. Thus when programing in the style suggested with 37signals and Pragmatic Programmers, you shouldn’t have to write large functions and blocks, everything should be broken up.
JD
I can’t believe anyone who have digged into RoR could have missed hearing about Basecamp so I’ll take your post as 5 reasons not to write things before one can back them up with good arguments, experience and facts.
On the positive side you seem to be an open-minded person.
“I can’t believe anyone who have digged into RoR could have missed hearing about Basecamp so I’ll take your post as 5 reasons not to write things before one can back them up with good arguments, experience and facts.”
I had good facts, I have examples, and I have experience. One example (basecamp) does not nullify my statements.
“On the positive side you seem to be an open-minded person”
I don’t like to get in pissing matches with other people about “why lanugage X is better”. Although I do like open source apps (php+apache+mysql), I am not against the many others that exist (asp,.net,etc). After delving into ruby and the rails framework, these are the conclusions I came up with. I try to stay as open-minded as possible.
“Justin, I actually appreciate this post as most of your reasons are rock solid, and your rebutal in comment 5 is pretty solid. I am a lover of RoR, so I would like to know what is wrong with the factorial code. If it is that the lack of braces and parenthesis is hard to read, then I want to make sure you know that the parenthesis can be used, I am not certain on braces, and RoR pushes DRY. Thus when programing in the style suggested with 37signals and Pragmatic Programmers, you shouldn’t have to write large functions and blocks, everything should be broken up.”
you make a very good point here as well. My point was this (which may not have come across very well in my article): in my experience with RoR, which includes looking over other peoples’ code (taking over a project), and writing some of my own, that it was very difficult to write a large app using syntax similar to the factorial code. The factorial code, on its own, is fine.
“…it was very difficult to write a large app using syntax similar to the factorial code.”
I think I understand your point, and I think it might be related to a difficulty with reading different syntax in general. For example, it was hard for me to read Python when I first encountered it, and it still is hard to read LISP (which is a different story all together.)
Just wondering, what is your opinion of the RoR framework in objective sense? What do you think of the overall simplicity behind it? And what do you think of the PHP and other replications of it like Django?
JD
Justin, my earlier comment ended up a bit offensive. My apologies, I regret phrasing it that way. I still don’t get reason 4. If that’s your idea of dirty code I wonder what you think of as clean code? Do you think the corresponding php code is cleaner?
If you have time please elaborate on why you think it would be difficult to write large apps using that kind of syntax.
Just add one more comment about the dirty code, here is a cleaner example
def factoral(n)
(1..n).inject { |fac, i| fac * i }
end
I know it doesn’t invalidate your argument but, there is always a cleaner way
Thanks Lewis
No problem mark.
as for your other questions:
I have been programming for about 10 years and learned using old school methodologies and languages (c,c++,assembly, and object pascal), but am now consulting with PHP, perl, and some RoR.
The Object orientated parts of the framework of RoR acually isn’t too bad (I did some heavy reasearch over the last couple of days to re-evaluate rails). Thinking about it now, my irritation with the language is mostly due tomost of code that I have come across that has been very difficult to read.
I really like objects and classes of PHP5. I’m glad to see improvements over Version 4 (public,private,inheritance,etc). I’m hoping when 6 finally comes out, it will be even better.
“Thinking about it now, my irritation with the language is mostly due tomost of code that I have come across that has been very difficult to read.”
Ok, I see. That’s a very understandable stance.
Our company used to use a Python framework and switched to rails for development. So far it looks like in order to run the same levels of projects we’re having to halve the number of sites and double the ram on each server to keep pace.
One site alone of ours uses 50+ apache processes to run. Our testbox had to be hard-booted when we tested it with that many Mongrel connections.
Also of note, Rubyonrails.com is PHP. As in: http://www.rubyonrails.com/index.php
Those are not very convincing reasons not to use Rails…..
I know its been months since you posted this article, but all five of these reasons still apply very well. RoR is not considered a conventional language yet, and I must agree that for web development PHP, ASP, and CGI which are tried and tested, should come first.
Ruby is a very good concept language. It integrates simple syntax with flexible pure OO. However, its two most heavy drawbacks are:
1. Requires CGI and Rails to develop server-side web applications. Memory-consumptive vs PHP, but superior to ASP here.
2. Is an interpreted scripting language. Runtime execution is extremely slow compared to C++ or even Java. Compiled binaries are inefficient and take more memory than C/Java equivalents.
I’ll have to agree with most of the other posts. Here are
Some Better reasons not to use rails.
Right tool for the job, I have no problem with that. One of the best things about ROR is it’s youth. It doesn’t have the bloat of other languages/frameworks.
One Line:
def fact(n); n * fact(n-1) unless n == 0; end
(This may be cheating, but it works
)
Rails (and ruby in general) is an excellent language, there are hundreds of ways to write code. Ruby takes a lot of the work off the programmer, but it is still the programmer’s job to write the code properly; you just have to start thinking the Ruby way
Dear folks, I am very intrigued by RoR. I am looking for examples of large applications built using RoR.
After checking Odeo and Basecamp: does anyone know another good, large RoR application? Please let me know by contributing to this thread.
Why I ask? Probably Jason’s reasons #1-5 can be overcome; successful large implementations can prove that.
Everyone agrees on the very impressive prototyping power, but the same was said about e.g. WebObjects, SmallTalk, Lisp, HyperCard and Python.
So now let’s see some real-world applications!
As a web developer on a RoR-like platform building large applications, I found out that the REAL time-burners are (in order of precedence):
1. getting all the 1000s of details right once the prototype works
2. building user interfaces which are friendly enough to keep the client from phoning the helpdesk all the time
3. reusing DRY OO-applications while meeting client demands causes “christmas tree formation”, hard upgrading, and lengthy refactoring
4. working around argument #2: very young tech works ok 99% of the cases but it takes hours to discover yours is in the 1% category
5. working around argument #5: with 100s or 1000s of objects your stuff works just fine, with 100.000s or millions, the stupidest, non-foreseeable side-FX have to be battled: exponentially slowing database above 17 mln records, memory allocator that slow to a crawl above 2GB of RAM, the kernel decides to swap out memory while there is plenty of RAM left, queries that take forever, hot-backup procedures that get longer very fast and jam the live database, long startup times… Jungle problems you cannot solve by just cramming more hardware in a 19′’ rack.
These problems are not at all platform or language related and are probably the reason that Justin Silverton raised argument #1.
So the real-world questions would be:
- in what respect can the power of RoR help overcome these problems?
- and which applications have done so, successfully?
I think that arguments #1, #3 will be overcome in time.
I think that argument #4 is not a Ruby problem but a human problem.
Even Perl or PHP code can look nice and orderly if you do your job well.
I’m really interested in your opinions on this.
I did some research and found some apps that couldn’t scale with RoR:
Twitter:
http://www.brandonwerner.com/2007/04/13/twitter-admits-ruby-on-rails-cant-scale/
another good article on the subject:
http://www.loudthinking.com/arc/000608.html
and a third article on how to scale ruby on rails to 4000 requests/sec
http://weblog.rubyonrails.org/2007/2/4/joyent-makes-rails-app-go-to-4-000-req-sec
Just for anyone running across this site and wondering if the links provided by Justin might have follow-ups, here’s DHH’s response to his own blog’s (now dead) link provided above:
http://www.loudthinking.com/posts/3-scaling-to-multiple-databases-with-rails
..and while MMC isn’t without it’s own flaws, it’s nothing that can’t be “fixed”.
I don’t know much about Ruby / Ruby on Rails. Just started evaluating. Still could not resist myself to put my comments. Because, even if I don’t know RoR, anyhow I can not buy your observations.
. Moreover no one writes dirty code than programmer himself 
).
1. It’s a buzz language
>> So what ? does that mean you should not adopt any thing which is in buzz ?
2. It’s young.
>> Lot of comments above, disagree to this. And I do agree to them
3. Poor support for IIS.
>> hmmmm… how about just saying “Avoid IIS-RoR combination”.
4. Creates dirty code
>> Lot of comments above, disagree to this. And I do agree to them
5. scalability
>> Don’t stop people from using it, otherwise how we will know the scalabilty
Conclusion
>> I think we can just say that ” Be cautious before investing too much … but we can take a chance at this stage of RoR..”
After all investments are most profitable when you take
chances at early stages…
What you prefer Microsoft shares at today’s price or at price 5-10 years before
Keep Walking ….
“After all investments are most profitable when you take
chances at early stages…”
Not in programming languages. With stocks, you have a chance at making lots of money by getting in at the ground floor. I am not going to take that same chance with RoR by having sub-standard and slower performing web applications. I will stick with a more mature language such as PHP.