Slashdot Mirror
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."
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.
I have come here to chew memory and kick ass... and malloc() is returning a null pointer.
what does it matter what other think anyway, if rails works for you, keep using it, otherwise there's something else that will work. Thats whats so great about choices and having opinions.
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 he points out.
Thank God for evolution.
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.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
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 you enjoy Rails, use it. If you want to experiment with other languages, go for it! Nobody is going to cast you out because you crave knowledge.
I use what I feel comfortable. I build do web design & development for a living. I feel comfortable in PHP as I can start from 0bytes to a full project with all of the problem solving logics coming from my own brain in PHP. I certainly don't rule other languages out, but I certainly am not as strong in them as in PHP.
No... I don't remember the point of this post. If you can figure it out, would you let me know?
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.
So to sum up: "yes, rails does suck in many ways, but if you are only interested in low use crud apps and static sites generated using rails, then its ok". Gee, how insightful, that's kinda what all the "rails sucks" people were saying in the first place isn't it?
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!"
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.
...but exactly why is the namespace within the controller so polluted?
Why can't I name a instance variable @template? (Just an example among others.)
Every programming language/framework has its own set of advantages and disadvantages. The trick is determining if a given language and/or framework does what you want in the way you want it done.
There are reasons my employer doesn't use Java everywhere, for example, and reasons why C or C++ is preferred in some contexts at my workplace while other languages are preferred in others.
In other words, it's quite possible that a given solution works very well for some people and can't cut it at all for others. One size of development tool does NOT fit all.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
... is the "Hype vs. Mature Usable Open Source Projects Built With It (TM)" Ratio.
By that Rails sucks, Ruby sucks even more, Django and Zope suck a little, TurboGears, etc. suck, Python itself fares quite well and PHP kicks everybody elses ass, Java included.
That aside it's pretty much a matter of taste and how well the core community is willing to push their product. Rails practically lifted open source project marketing to a whole new level - they deserve the attention they get. It's up to the ones using these webkits to seperate hype from reality.
We suffer more in our imagination than in reality. - Seneca
This is 100% exactly the same argument presented whenever an Open Source app is criticized.
Shut up about it!
How about instead of whining about people whining about their software, Rails advocates fix some of the issues causing arguments against their framework? Most of the people whining aren't capable of writing their own code to fix their problems with Rails, but their rants should be taken as SUGGESTIONS by the developers, not railed (no pun intended, seriously) against by a community full of zealots.
The same applies to all of the OSS fanatics who make this argument about *every* *single* *piece* of software, ever.
Yeah, sure, people should be a little more grateful.
But does the project being free protect it from criticism? It shouldn't.
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?).
That's a good measure for those who have no intention of developing with the technology. However when I evalute something's technical merits, I actually try to make something with it.
If it handles certain tasks better than other methods I know, it's useful.
If it assumes too much about how I'm supposed to use it, its much less useful. Not being thread-safe, not having both blocking and non-blocking versions of certain API calls, etc are all points against a product. I also grade on elegance of design. There's an old saying, what do you get when you mix 100 gallons of ice cream and a teaspoon of shit. 100 gallons of shit. If the layer below the one you're writing is poorly designed, the design flaws will invariably propogate upward.
One last point about these "easy to use" frameworks geared towards the average folk. The more complex details you hide trying to make it simple to use, the easier it becomes to use it wrong unknowingly. There is no silver bullet to get around algorithm efficiency, and a properly ingrained understanding of how computers solve problems and how to classify various problem types. Teaching someone to use an over-powered IDE and giving them a certificate which says that they know how to make programs that run, is no assurance that those programs will run well.
The author of the opinion piece said Rails helps smart people write a certain type of program faster. That is an arrogant statement, there are plenty of smart people without the formal training the author has had which probably use Rails poorly. It would have been more accurate to say, "Rails helps people who think a certain way accomplish a limited subset of tasks faster."
The more I read, the more both sides of this drama sound like elitist pricks, which can be an epidemic among web communities. Some very smart people over compensate for not having been popular in High School and create exclusive online communities rather than inclusive ones, these people tend to handle any criticism very poorly. Of course these people get worn down by people demanding so much from them without ever offering any compensation for their time.
If you want a good measure of what sort of people are in a given community, go to their IRC channel and ask a question from their FAQ.
(Disclaimer: not a web developer, never used Rails, no plans to in the near future)
I've mostly liked RoR, from the small amount I've used it. I'd use it more, only I keep starting projects with it, realize it's probably not the right tool, and then switch to something else.
/., you're good. But how does it fair for more general apps?
Part of the problem might very well come from the fact that I have very little experience with it (catch-22?). The thing is, from what I can tell, it's really specialized. I never had this problem with PHP or ModPython.
The article itself is a bit annoying, as it's about as vague as one can get. For us unenlightened, *when* is the proper time to use RoR? I get it's DB driven. So if you have to write a store, library, or
One of the big things that worries me is that there are a lot of files generated. That scares me. What if I made a mistake at the beginning? Is it easy to go back? Do I need to start from scratch?
I'm sure there is documentation somewhere that mentions that, only I haven't found it yet. I've come across plenty of 'how to start' articles, but not many that really get at the architecture design as a whole. Though, this seems fairly status quo for web-development.
As other posters have noted, many of these complaints/thoughts come from RoR being a framework. I wonder if it would be possible to re-create RoR, but in a more library-form. User has to do more work (no generated files), but more flexibility in the long run?
So RoR can't be used to solve every problem on the planet?
People get to hung up on a platform or tool. The worst thing anyone could do is to blindly give a project to a dedicated RoR or PHP or Java developer. It should be given to a developer who may enlist an implementation technology expert to implement it.
Software projects fail because they get hung up on implementation, don't have enough design or don't have correctly formatted requirements. if projects fail in implementation its being done by a group of idiots and deserved to fail.
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.
"Honey, it's not working out; I think we should make our relationship open-source."
I've asked the question below in other fora, but could never find a conclusive answer; here's hoping that /. wisdom will change that...
So, when people complain about Rails being slow, just how slow are we talking about? Are we talking in the range of 10s, 100s, or 1000s of requests per second? And how does it compare to PHP, the Python-based frameworks, etc?
Imagine I created a simple "hello world" dynamic page: something that when given a number as parameter, would return "the double of $num is $double". Imagine you would call it with http://whatever/get_double?num=10. How many req/sec would you expect on a decent machine with your favourite CGI language or web framework?
(And yes, I realise just how awfully simplistic this example is, but I would like to get a ballpark figure). Thanks!
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.
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.
Amen.
I never used Rails, I don't write web apps and, frankly, I have no interest in it. So I've been following all this by curiosity, because I might have to or want to later, and just for the amusement. I tried reading the other guys' (Zed) rant and stopped a third through because I felt he was just flaming everyone and not saying anything interesting (read: technical). His main critic seemed to be that the RoR guys are arrogant. Like he wasn't.
Now I get his point about arrogance.
This "rebuttal", which I read in its entirety, is *dripping* it.
First there's this point you mention. I could never understand this attitude from some open source developer, or sometimes projects, that users should be happy enough with what they have, and if they got problems, too bad. How difficult is it to say "Very sorry, this will not be addressed in the 2.x versions as it would require too many changes, but we'll take it into consideration when we start working on 3.0. Thanks for your input. BTW, you could mitigate the issue by doing xyz...". Instead it's like "You sucker believed the hype and now you're up shit creek? Tough luck! We know where we're going, we've got a *vision*, you see, and we don't care about mere users problems. But you should thank me for getting you halfway there." Arrogance. Abysmal. "You can rip out the bits you like and discard the rest." says he. I'm glad to submit bug fixes or new functionality to an open source project I use, but if I have to tear it apart to get something useful, it's shit, end of story.
Then there's the "Rail isn't perfect" thing, with the thinly veiled ad-hominem on "immature" people. Guess what? Nobody's looking for perfect. They're looking for the best, or at least the better. What kind of person answers "that's not so good" by "nothing's perfect"? Arrogants, that's who. I already *know* nothing's perfect, what I need to know is how your is stuff *better*!
Third is the one size doesn't fits all argument. When somebody doesn't address criticisms such as "it doesn't scale", "it uses up loads of ram" and "it's not thread-safe", explains that "[if you have SQL bottlenecks you can] bypass it with some inline SQL or even memcache" and "Rails code [...] is so clean and easy to work with that locating and optimising bottlenecks is a breeze", and *then* claim that "Rails is extremely good for [medium to large web applications] of applications", I know one thing: he doesn't have the faintest clue having anything large in IT. All he knows is performance hacks. Which is good, mind you, but not enough when you're dealing with large apps. He's talking about profiling. I'm impressed, that's been around for, what, 20 years? The problem is not optimising the app, the problem is what you do after you've done that and you still have a performance barrier. Oh, yeah, and "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." Is that so? I'm doing it wrong I guess then! It means Rails isn't right for my project, and that's *it*! Arrogance again...
I won't dwelve into the "Smart people might not like rails, but rails is only for them. Idiots stay away." As far as I know, the hallmark of a good library or framework is to be able to make the difficult easy and the impossible possible. Apparently rails doesn't cut it.
And finally "rails is teh most flexible". Well for all I know, it is. Any facts to back that up? Cuz the examples didn't exactly convince me. For one thing every single OR mapping I've used allows custom tables and custom SQL queries. I got news for him: "most other frameworks" have thought of bypass and override...
In conclusion: like I said, I don't use Rails and I don't do webapps, but "If you decide Rails isn't for [your project, not "you", but presumably it implies that you're not smart enough to get it], *do* post a rant about how it sucks". You may make yourself look bad (maybe even "dumb"), but the better of those rants will end up being linked to the top of google, so the people who have not tried it yet will have a way to form an opinion. Thanks.
The proper response to a jack-off is to ignore him.
That being said, said jack-off actually *tried out your stuff*, didn't like it and *said so*. "You should lick my boots for getting that much" is not an appropriate answer, ever, even though I understand why one might feel like saying it. At what point do you start considering what jack-offs said? If a thousand jack-offs post the same complaint, does it become data? It should.
I've done a lot of C++ coding. Designed several PHP websites. I've had to maintain a good amount of Perl code. My Ruby experience is mainly just playing around.
Recently, my girlfriend got me started on writing a book recommendation website for her. I had heard a lot of things about Ruby on Rails, so I decided to buy a book and give it a try. I like the AJAX integration. I've never used javascript, and it was easy to jump right into that. The database integration is also neat -- it handles a lot of the grunt work for me.
More than anything I'm worried about speed. Like I said at the beginning, I come from a strong C++ background. The philosophy there is basically do things at a high level, but the speed should be there if you need it. And yes, I've needed it at various, often unexpected, times in my career.
I'm also a little worried about reliable APIs. The RoR team seems to have a habit of breaking things with new releases. Since web security depends on updates, leaving things unpatched doesn't strike me as a wonderful solution. But hey, this is just a play website I'm building. I'm having fun, and I guess I'll find out whether the framework lives up to expectations or is more trouble than it's worth.
Absolutely correct. You can criticize an open source program all you want, and good criticism can be a boon to a project. But there are some lines that you don't have a right to cross. One is when you say, "so hurry up and fix it!" Unless you're willing to front the money or do the coding, you're not in a position to make demands.
Another line is the thin line that separates constructive criticism from mere douchebaggery. It's easy for frustration with a framework to bleed over into personal attacks against its authors or its fans.
Lastly, the article is right to point out that a lot of criticisms about any project are simply false as a matter of fact. Those can be especially frustrating for the people working on a project.
Just expect people to be emotionally invested in their favorite projects, and to know it too well to see your objections as major obstacles. So they may not take your complaints as seriously as you'd like.
You want the truthiness? You can't handle the truthiness!
Have you heard of Perl?
Now, it's possible that you're defining "Usable" as "Not in Perl", but Perl has more mature, high quality code available in it than any other "web language".
-- The act of censorship is always worse than whatever is being censored. Always.
True enough, but remember: The set of communities with assholes in them and the set of communities that produce useful software tools overlap almost entirely.
-- The act of censorship is always worse than whatever is being censored. Always.
Just for the record, the author did a physics degree with no IT component (a great many years ago), and taught himself Rails in a few weeks over the summer. No formal training.
Carpe Diem
I tried running Ruby on Rails on my cellphone and, let me tell you ... it truly sucks monkey balls.
... I've been coding my latest web app in Assembly for *some time now*
On the other hand
It's taking a little longer than I (or the client) had initially anticipated, but it's very stable.
( If only I could figure out why I can't get AppleScript running on my Xbox!! )
I don't know the people involved, but most people I do know that are involved in the open source community like the CCC guys have pretty amazing stories too. There are a LOT of good people out there, unfortunately the idiots are the loudest and this guy decided to feed the troll, which means he's not part of the solution if you get my drift.
I disagree. I'm a supporter of multi-paradigm programming ("the right tool for the right job") and consider functional programming approaches the most important of all. I find Python very comfortable to work with, and much conceptually cleaner than Ruby.
While Ruby has one advantage or two over Python, such as multi-expression lambdas and Python's statements turned to expressions (statements are a common root of evil and an unnecessary procedural concept), the main problems I see in Ruby as a language, leaving libraries aside, are that it has several different implementations of the same concept of function - blocks, procs and methods, having mediocre first-class function support due to keeping that silly value vs. function value behaviour inherited from the equivalent Common Lisp misfeature, completely misunderstanding properties (partly as a result of the former: a method should really be just a property which happens to be a function, or an object that can be used with the (...) operator), and having unnecessary complexity and irregularity in the syntax which is good for nothing and bad for everything. I suppose people who enjoy Perl may enjoy Ruby in the sense that it feels like you're writing some kind of "seekret haxxor code", but all you're really doing is spend about the same time writing a much less readable and maintainable program that looks like ass.
I'd like to post quote from the first words of R6RS, the Scheme standard, which I consider to be the ultimate design criteria, not only for programming languages, but for software in general, and perhaps things beyond software:
"Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary."
I was about to say 13256278887989457651018865901401704640, but it appears this number is private property.
The trouble is that RoR does have some serious issues - for example, it's apparently impossible to deploy in a shared-hosting environment.. Supposedly, the solution is for Dreamhost to "Wipe the wah-wah tears off [their] chin" and realise that the RoR community just don't care about shared hosting.
Seriously, what kind of legitimate news report runs with that kind of headline?
Welcome to the real world, Ruby developers. There's been so much hype around Ruby, and especially Rails, for a few years now that no one has even been allowed to voice an opinion that makes negative remarks about either. That honeymoon period is now well and truly over.
But pretty much every langauge community, and especially in the realm of dynamic languages Ruby is in, where there's a lot of solid competition, has to deal with criticism. You'll quickly find that, even though a lot of it might have a grain of truth in it, the vast majority is blown utterly out of proportion. Coming from the Perl community, I've seen as much of this as anyone.
In the end, you have to learn to live with it. Some of it may be interesting and useful, and as a community you need to learn how to pick out the good criticism and incorporate it where possible. As for the completely baseless FUD, it's largely irrelevant. For every person who reads that FUD and is put off, there's another who looks at the language, how popular it is, and decides they'll make up their *own* mind. Those are really the people you want in your community anyway.
Anyway, I like Ruby as a language, and - while it doesn't really fit in with my way of thinking - I can definitely see the appeal of Rails. And, long term, it'll be a good thing for the langauge that the hype period is over. Now the serious work can begin.
RoR sucks so badly, that actually needs these kind of cheap troll articles to advertise it. Sorry guys, but a programming language is designed to implement solutions, not just make the coder feel good (for 1-2 days). Learning curve is completely unacceptable. If you want to feel "special", go have fun coding in Ruby. But if you want to produce a big scale software solution, go use a proved language/software platform, like Java EE or .NET.
Saying that "you need to be smarter to understand it" is actually an argument against RoR.
And PHP deserved it more at the time but look at it now.... RoR will continue to mature and improve and people will use it when it is appropriate
I don't use it cause I don't have time to learn it but if I hired a new developer who knew it well I'd definitely consider it for some projects.
A fool throws a stone into a well and a thousand sages can not remove it.
Hey! that one should make a rather good signature ...
-- "As a human being I claim the right to be widely inconsistent", John Peel
Why isn't this article showing up on the "Developer" summary list that I set on slashdot via preferences? It's not older than the oldest one listed.
Table-ized A.I.
I feel that Rails did make a large contribution to web development in general. There are now similar frameworks in basically every language out there. Even Java has a RoR look a like (JBoss Seam).
However, the biggest issue I feel is the whole "Convention over configuration" mantra. Yes a framework should have sane defaults (convention), however, in my experience using Rails, Django, Seam, and PHPCake, Rails by far makes it harder to do something that is not a "default". Want to use it with an existing DB? django and seam both have a beautiful utility that will build your code from that DB. RoR says: you must rename all your db tables to plural (which I was taught in school was 100% wrong btw... I was always taught singular for table names... but maybe my professors were smoking something? At any rate, all of my existing DBs had singular table names when I started messing with Rails), or spend hours adding configuration to your app to properly map models to tables.
There are many other issues I ran into using Rails along these lines and others, but basically it always seemed like in Rails it is very much an all or nothing proposition. Either your application/design/db fits and it is all going to work, or there is need xyz which is outside of Rails features, and therefore, you can't use any of rails.
Django is my favorite of the 4 frameworks listed, specifically because it makes it so easy to use parts and pieces of the framework, where it makes sense, or not use it for other parts. It is by far the most flexible to me. And yes, there is some configuration needed, but not much more than RoR. The nice thing is django has a flexible and powerful configuration system. it isn't a second class citizen like most configuration in RoR (if a configuration option is even provided in RoR). Most of the time in RoR it seems like they said "Well, this is HOW you do this" and if you want to do it a different way, there isn't even an option anywhere to change it. You can either re-write the RoR functionality to match how you want to do it, or not use RoR. In reality though, these changes could be implemented as a simple configuration change. But because RoR eschews configuration like the plague, you're just stuck with 2 bad choices (reimplement, or don't use RoR).
This isn't to say RoR sucks, I'm just pointing out my reasoning for using a competing product.