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

This just seems like nonsense.

I am not a RoR developer, but I don't think the language or framework sucks. I've actually adopted a few ideas from it, but I still work much more efficiently in PHP as that is what I am familiar with. I have lots of respect for the guys at 37 Signals and the Ruby developers and I imagine it must be tiresome hearing about how much your language sucks. Still, this article is just worthless. The first two points seem to be saying "Rails isn't really unsuitable for your project because it is free and nothing is really perfect anyway." Then there's the logical fallacy embedded in the statement "If Rails isn't right for your project, that doesn't mean that Rails sucks. It just means that your project isn't right for Rails." Sorry, if Rails isn't right for my project, then that means Rails isn't right for my project. It's like trying to shift the blame for inadequacy from the tool to the task. I'm not buying it. The author then goes on to state that Rails is only for "smart people" and then makes the baseless claim like "It's much harder to fake being a good Rails developer than it is to fake being a good PHP developer." At this point, he's lost me. Listen, folks, Rails is the right answer some of the time and it's the wrong answer some of the time. Just like any language. SQL, Javascript, PHP, Rails, C, Java: they all have things they are good at and things they are bad at. The author at least gets that part right, but then goes on to undermine it repeatedly. At the end of the day, articles like this only encourage the detractors and scare away the uninformed.

Re:This just seems like nonsense.

Let me summarize the wall of text ;)

Use the right tool, for the right job.

Re:

Very true. Rails has deployment issues. See here, and especially read the comments: http://www.rubyinside.com/no-true-mod_ruby-is-damaging-rubys-viability-on-the-web-693.html [rubyinside.com]

Re:

Has it really? I don't think that Java has survived the lack of mod_java. There are very few webhosts that offer Java. And when they do, it's usually quite more cumbersome to use than PHP, because in certain configurations it requires reboots of the ser

Basically...

Rails doesn't suck because {insert boiler plate reasons of why rants against any language/framework are wrong}. I think he's right, but there's not much really Rails-specific in the article. In fact, there's hardly even anything countering the criticisms h

Submission may not suck.

May not suck... Wow, such strong verbiage. How can you possibly defend such a rigid stance?

Next time you're trying to defend something, don't start from 'may not suck'. Try something a little more positive.

I don't get it

Yes, people need to stop complaining that it doesn't conform to their ideas and values and it's "different".

I don't know how many times it has to be reiterated: use the tool that suits your needs.

To the author of the article, live and let live. If yo

Too Generic

This guy's arguments are too generic for me. I don't personally use RoR, nor do I do web development, but I do program, and it seems to me that this guy's arguments can just as easily be applied to any free programming language:

1. (Programming language) owes you nothing
2. (Programming language) isn't perfect
3. (Programming language) isn't suited for all applications
4. (Programming language) isn't suited for all people

The only point he has that doesn't necessarily apply to all languages is:

5. Rails is extremely flexible

I take the first four points as being self-evident for any programming language. It's actually a good list for explaining why there are tons of different languages out there. The reasons stated in the article explain *how* Rails matches with the first four points, but don't really explain why that makes it objectively *does not suck*.

The fifth is the only one that seems to have any sort of Rails-specific content to it; and like I said before, I'm not a web dev so I can't comment on it's validity.

Ultimately, I think the message that can be gleaned is this: that like every other programming language in existence, it is good for some and bad for others.

Re:Too Generic

you got much further then me... I abandoned this passage;

In fact, there's no such thing as a perfect anything - whether in the world of computers or outside of it. Everything is imperfect. If you want perfect, then die. If the Christians are right, you might go to heaven and witness perfection. I wouldn't bet my life on it though.

How can anyone be taken seriously after such a remark?

Re:

Meh. I once saw a man state that the Christians are right and that they (and only they) will go to heaven and witness perfection. He said this several times, in fact. And more than a hundred people, all congregated around him, continued taking him seriousl

Re:Too Generic

5. Rails is extremely flexible

I'm a Rails developer, and I have to say I disagree with this. When you work within Rail's comfort zone, it's a joy to develop in. But start to edge outside those boundaries, and suddenly everything starts to fall apart. A lot of things that could be made modular are currently hard coded, especially in the monolithic and huge ActiveRecord. Rails is designed to work well given certain conditions, but try to do anything clever or unusual, and it's a toss up whether you'll get away with it without running into problems.

Rails may be a nice framework, but flexible it ain't.

Ruby

I'd never used RoR or even Ruby, but I was hearing a lot about it and I had a hobby project that I wanted to start on, so I bought an RoR book, and spent HOURS working on it. Then I gave up, having accomplished nothing, switched to Django (mind you, I'd never used Python before, either) and started getting stuff done.

(Well, a more full story is: I started with Ruby, switched to Django, realized my host doesn't support it, tried Ruby again [now I understood the framework better, from using Django, but the language still looked like Swahili], then moved to CakePHP which IS supported by my host, realized how much easier and less-fussy Django was, decided "to hell with my host, I'll get a new one if I ever decide to take this code live" and finally went with that.)

My hang up with RoR is the Ruby part. It's completely unreadable to me. Python, I could understand reasonably well before I even started reading any "learn Pythong" material. Same with most other languages. Any Ruby code beyond "hello world" and simple arithmetic looks like gibberish to me.

However! My first language was Perl. People often complain about how hard it is to read, and I instinctively bristle a bit when they do, because to me, it's the easiest language to read. The reason? Perl code tells a skilled Perl coder TONS about what it's doing and how, but confuses newbies like crazy. Ruby strikes me as being much the same way.

So, I understand why people who have taken the time to really learn it enjoy it so much, but for me it's so much easier to choose a framework that uses a "pick up and go" language like Python and be done with it. It does the same stuff, and I can get right to learning and working with the framework rather than dicking around with the underlying language.

I'm really not trying to pick on the RoR people, nor being petty (really!). I know it's a good framework, and I know that if I took the time to learn it I would like it just fine. Just getting a perspective out there that's not "rah rah, RoR is the best thing ever!" or "boo, RoR ran over my puppy!"

Re:

Man, all these crazy names are hard to keep track of. At first I thought you tried and failed at Ruby, said "screw it" to the coding, and switched to spaghetti westerns. [wikipedia.org]

Re:

The Ruby versus Python thing has puzzled me for a while: most people who prefer Python over Ruby seem to find Ruby unreadable, whereas most people who prefer Ruby over Python can read Python okay but don't enjoy programming in it. Both camps seem to disag

Re:

Do you think that's the issue, or something else?

OK, I'm not going to list ever language I've ever used or otherwise enter a bragging contest, but please just take me at face value when I say I've been around the block a few times. To me, Ruby "feels" like it's trying to be clever. I hate clever, not

Blame the programmer not the language

A lot of Ruby tutorials do try to be overly clever. But really, quite a bit of C code was/is overly clever, also. People cramming so much stuff onto a single line that the code is unreadable and difficult to support.

But that's not really a problem in the language. That's a style thing. I very frequently when coding in C, Java, or C# split things onto multiple lines that could be expressed in a single line. I often take intermediate values and put them into variables with good names, instead of ramming the values all together.

I remember when I was a wee lad, learning C, and being utterly baffled by a lot of the code I read. Casting pointers to other things, doing math, switching to array notation, then suddenly treating the whole expression as a function pointer, and feeding a stream of other things as arguments into the function... That kind of thing is amusing, but has no place in typical production applications code. Something far more common is huge expressions with the ternary operator that are just one element in a more complex expression. I saw this kind of thing in most of the C code I read, and felt like I must be a noob if I didn't do that. Then one day I decided I just would write code that was simple and made sense, and that's what I do-- it's a style choice.

The point is, writing code that's easy to understand is up to the programmer, and less to the language. People used to defend COBOL because it was more readable. But one huge problem with COBOL is you've gotta write a lot of lines of drivel to get anything done, compared to say C. The price we pay for the comparative expressiveness of C is we have to be more careful with the code to keep it understandable. From C to Ruby is a similar jump in expressiveness, with a commensurate risk of it being less understandable. But it's possible to write difficult to understand code in any language.

Ruby does have some things in it that make it quite different from other languages, most notably closures and metaprogramming. But honest, you do get used to it. You can even avoid the elements you're not comfortable with, and ease into them later.

But over time you start to find there's quick and dirty ways of doing things in very few lines of code in Ruby. And things like testing kits and the way Rails helps you structure your code make it so that your code is spread out nicely, and it's easy to isolate bugs quickly, even if some of your code is a little overly terse.

I recommend not starting with Rails. Spend a few hours alone with Ruby before trying to wrap your head around the way Rails works. Write a tic tac toe program on the console, or something. Get to where you've made peace with Ruby before you get into rails.

Because starting off directly with Rails and Ruby, not understanding either one can be very difficult. They are both such different approaches from what many developers are used to that it's a bit like learning Pig Latin and Chinese at the same time.

Re:Ruby

Ruby code beyond "hello world" and simple arithmetic looks like gibberish to me.

Ruby looked like gibberish to me, too. Coming from ARexx (heh) and PHP, with a bit of C etc, seeing:

%w{foo bar}.map {|e| e.upcase }

Simply didn't mean anything to me; map? What are those {}'s doing? What's |e|? What the fuck's %w{}?! It's bit of a triple-whammy really; first you've got a bit of perlish shorthand (%w{foo bar} == ['foo', 'bar']; make an array containing these words), second you've got a code block with slightly Smalltalkish parameter syntax, and third you've got an unfamiliar verb "map".

But you're right, once you actually grasp some of the concepts (and if you don't know about things like map/select/reject/inject (reduce), you really fucking should, I don't care what language you use) and the basics of the syntax, it all just flows; make an array, make a new array from it by running the upcase method on each element, just like:

array_map('strtoupper', array('foo','bar'));

Only it doesn't fall to bits when you want to do non-trivial things to the elements. After that, it's mostly getting familiar with what the other methods do and getting used to using/chaining them. If it doesn't go from confusing to obvious or even useful outside Ruby in an hour or two, you're probably doing it wrong.

Similarly when it comes to things like metaprogramming; it starts off confusing and ends up being a force multiplier for your work. The confusion hopefully means you're learning something new, and you don't become a better programmer by running away from that.

"[Open-source project] owes you nothing" arguments

Why does this argument, or something like it, always get repeated when somebody criticises an open-source project?

The Rails core team also doesn't owe you anything. They are all volunteers who work on it for free. You owe them.

So stop thinking that Rails owes you something. Rails owes you nothing. You owe Rails.

In what way does criticising something suggest I think its authors owe me something? I mean, I'm highly critical of the GIMP at times, particular its Windows "port" which fails to adhere to anything remotely resembling platform standards, but does that mean I think the GIMP's authors _owe_ me something? No. If anything, it means I _hope_ to be able to _give something back to them_ by making criticisms that they could take and use to _improve their software_, which presumably they do care about. It means I don't recommend people try it unless they're willing to accept software that behaves in odd ways.

Re:"[Open-source project] owes you nothing" argume

You should think of the "X owes you nothing" argument as a response to certain not-named-here jackoffs who have some sort of trouble with an OS project, get pissed off, and post indignant messages to mailing lists or forums. "I can't figure out X! You guys suck for not making X more clear! Fix it now or my company will never use X!"

The only proper response to this is that X owes you nothing.

So if someone says "Rails doesn't scale/Rails is too slow/Rails isn't easy enough for me, fix it right now!" then the response is clear.

In your case, filing a bug against windows GIMP and calmly explaining why you think it's broken is much more likely to get a serious appraisal at some point -- while some asshole (not you) who just complains about it feels an unearned sense of entitlement and should simply be ignored.

Like I always say

You never really know a system until you hate it.

Of course, hating a system doesn't mean you know it. You can hate a system in a completely uninformed way.

Now back when I got involved with computers, in the 70s, it wasn't like this. We didn't have frameworks, we had libraries. Either a library met you needs and you used it, blessing its authors, or it didn't and you didn't use it. Of course people didn't expect much from applications back then, either. Programs by in large just started up, did something useful, then went away. There was a whole "software tools" philosophy built around this very idea: write programs that do one thing (usually some kind of filtering task), then go away.

By contrast all but the meanest programs today look like operating systems. They're supposed to run forever an take god knows what input from god knows where and do precisely what the designer wanted them to do, plus whatever he would have wanted them to do if he had had the foresight, but nothing else.

And you've got to choose a framework. It's not just diving into a program and deciding you need something that's in a library somewhere. It's not just choosing a framework before you really know what your application has to do. You've got to choose the framework before you interview for the job. So really, life as a programmer involves relatively less solving of real problems and relatively more finding ways to hammer square pegs into round holes.

It's not that writing software is any less fun than they were back in the day. It's that on top of being fun its goddamned annoying.

this article is useless

unless i get a description of the author's prowess in martial arts and ability to kick my ass in a general time frame (10 seconds? 2 minutes?).

Speed and Protection

Ruby and Rails are delicious, but there's 2 things I need that I can't get from Ruby on Rails right now. Because of these 2 things, I am using C# under Mono, but I'd far rather use Ruby on Rails if I could:

1. Protect the code. I need to be able to deploy it without the code being easily copied and reviewed. I know, I've seen it all on this topic: I don't really need to protect it, whatever I'm doing isn't that hard to figure out, etc. Trust me, I really need to protect the code. I write products for a living, and my customers will unfairly pirate/sell/give my code away, and it will cut into my income if I can't keep control of who gets my code. This is why I'm using C# and Mono. And yes, I realize that can easily be decompiled. But it's still more than adequate protection in my business space.

2. Make it faster. Ruby is too slow for what I need to do. My customers can only afford around $100 USD/mo for hosting my special purpose application, and for the number of people they get hitting the site, Ruby doesn't cut it. I know, I know, do more caching do more magic, get more computers, build a server farm, etc. Whatever. I just rewrote the thing in C# and I could support way more users per $100 of server. It made me cry to have to do it.

Please, if there's ways to do better on those 2 areas, let me know! But trust me, I really do need to protect the code.

I'm thinking I might be able to solve both of these problems using JRuby some day, but I'm not sure yet.

Re:

As long as you don't change the DB too much. Obviously since you are creating a class representation of the database, how much gets altered will certainly muck things up.

It seems that RoR makes heavy reliance on this relationship, which is where it gets it

Re:

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 eas

Re:My experience with RoR

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.