Rails May Not Suck

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

Re:This just seems like nonsense.

[nschubach]

Let me summarize the wall of text ;)

Use the right tool, for the right job.

Re:This just seems like nonsense.

[morbiuswilters]

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

[I Like Pudding]

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.

Re:Just how slow is "slow"?

[Unoti]

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.

Re:My experience with RoR

[Chandon Seldon]

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.