Forgot your password?
typodupeerror
Programming IT

Rails May Not Suck 160

Posted by timothy
from the isn't-the-question-whether-rails-suck dept.
KDan writes "With astonishing regularity, articles or posts come out claiming that the popular Ruby on Rails framework sucks in some way or another. People complain that Rails isn't as easy to deploy as PHP, that Rails just didn't do it for project XYZ. They range from the articulate and well thought out to the frankly inane and stupid (and wrong). Recently, there's also of course been the spectacular nuclear rant by Zed Shaw, which was more a rant against random elements of the community than against Rails, but was still presented as a rant against Rails. Here's an article that tries to put some perspective on why these opinions are irrelevant to whether or not Rails sucks."
This discussion has been archived. No new comments can be posted.

Rails May Not Suck

Comments Filter:
  • by nschubach (922175) on Thursday January 10, 2008 @06:03PM (#21991254) Journal
    Let me summarize the wall of text ;)

    Use the right tool, for the right job.
  • by morbiuswilters (604447) on Thursday January 10, 2008 @06:20PM (#21991568)
    I agree that developers often try to use the wrong tool for the job. However, I think statements like "your task may not be suitable for Rails" only reinforce that. It's implying that Rails is the goal and that kind of thinking contributes to so many awful technical decisions, for any language.

    You need to be pragmatic and smart to get the most out of any language, framework or tool. Rails can't make you write spaghetti code and I'm sure many people who bash Rails didn't take the time to learn how to properly use the tool, but that still doesn't mean that Rails protects against stupidity any more than PHP does.
  • Re:Ruby (Score:2, Informative)

    by I Like Pudding (323363) on Thursday January 10, 2008 @08:50PM (#21993482)

    Imagine if Perl had special syntax for passing anonymous subs as arguments, and idiomatic Perl code used them for everything all the way down to most looping constructs...

    HMMMMMM...

    @sorted = map { $_->[0] }
              sort { $a->[1] cmp $b->[1] }
              map { [$_, foo($_)] }
              @unsorted;
    Now back to work with you! I want a ruby runtime that doesn't suck already.
  • by Unoti (731964) on Thursday January 10, 2008 @09:17PM (#21993778) Journal
    There's 3 aspects to the slowness, IMHO:

    1. The language. Ruby tends to be slower. Something like this programming language shootout [dada.perl.it] will give you details. But this isn't the whole story.

    2. Enough rope to hang you. Rails gives you a lot of ways to easily define dynamic classes, where the class is being generated dynamically on the fly. It can make the code lovely and small to use, but can make it slower than hammering it out in a lower level language. This and other techniques can lead to higher memory consumption, too. But I don't fault the language here. I see it as a powerful tool that must be wielded carefully sometimes.

    3. Active record. A lot of the slowness that people see can come from automagic that's happening in the background. If you're not careful with active record, for example, it pulls in every last field from table you're looking for, along with the relatives. I just needed the customer's name, and ended up with 8 kilobytes of data because I wasn't careful with what I was doing.

  • by Chandon Seldon (43083) on Friday January 11, 2008 @12:08AM (#21995024) Homepage

    More than anything I'm worried about speed.

    The standard story for dynamic language development applies:

    • Optimizing before you have a problem is a waste of time.
    • There are lots of ways to optimize, up to and including re-writing the bottlenecks in C/C++.

    The most common optimization that's used with Rails is it's built-in support for caching, which can speed things up by quite a bit. You can get the same sort of results with a hand-optimized memcached setup any other dynamic language - but Rails gives it to you almost for free.

A LISP programmer knows the value of everything, but the cost of nothing. -- Alan Perlis

Working...