

Some HNers seem to hate Rails. I want to know why. - generalk
http://joncanady.com/2010/09/13/when-has-ruby-on-rails-failed/

======
BrandonM
<rant>

If I'm a good C programmer, if I grok Lisp, if I'm fluent in Python, if I can
accomplish damn near any file munging task from a bash prompt, and if I have
an understanding of component-based development, then I should be suitable for
the vast majority of programming jobs. Yet something like 90% of job postings
require X years of experience in Ruby, PHP, Java, or some Microsoft-specific
language. Many of the interesting programming jobs have chosen to select for a
language that I could learn in a couple hours, work with in a couple days, and
use well in a couple weeks, but because I don't know it _right now_ , I'm not
hire-able.

 _Background, intelligence, and work ethic be damned, you need Ruby and Rails
experience to work here, because after all we have many applicants and someone
is bound to fit all our criteria. And while we're on our soapbox, why-oh-why
are good programmers so hard to find?_ Because you're not even trying. You
have too much other crap to do, and you're just looking for a quick, safe
reason to reject everyone else and have a couple people conveniently left over
to choose from. And no, I don't know the ins and outs of b-trees anymore, but
give me some time with Google and vim and I'll have a C solution ready to be
tested. You know, the way real work is done.

So yeah, I suppose I do find myself bitter that I'm expected to pick up a
trendy language and platform (and recall every data structure I learned 4
years ago) to even have a chance on the job market. From the outside it just
looks like a giant Ruby/Rails clique (or PHP/Cake, or Java/Spring, or whatever
technology your company has happened to fall into). We're all forced to learn
something that we don't _actually_ need -- we can already get it done with
similar effort in another way -- just for you to consider hiring us. And
everyone has a slightly different stack that I have to go teach myself just to
avoid looking like an idiot in the application process.

And it's not just Rails and the languages I don't know (yet!). Even the Python
job postings I find almost without fail require experience with Django or some
other framework _du jour_. I mean geez, how long does it take to learn a
freaking framework, especially with a bit of early guidance? Stop selecting
for the wrong criteria!

I'm not one of the ones typically "bashing" Rails, but I understand the
frustration of being forced to learn a bunch of crap as part of an elaborate
mating game of inefficient, badly-designed hiring practices. Just throw some
work my way, give me the email of a knowledgeable employee who can answer
occasional questions, start me out at a below-market rate, and evaluate my
role and contributions in a month or two when I've had a chance to get
acclimated. The filters that employers use are such bullshit, and then to make
it worse they slap us in the face by claiming that it's impossible to find
good programmers.

</rant>

What was the question again?

~~~
JangoSteve
I'm not saying I disagree with the principle (I very much agree that it
shouldn't be this way), but this seems like a rather impractical argument.

 _a language that I could learn in a couple hours, work with in a couple days,
and use well in a couple weeks

...

I do find myself bitter that I'm expected to pick up a trendy language and
platform (and have arbitrary recall of every data structure I learned 4 years
ago) to even have a chance on the job market._

Are you saying you feel you don't have a chance on the job market, and that
you'd really like to have a shot at all the Ruby jobs out there? Why not spend
a couple days becoming proficient hacking together a couple OS projects (or
contributions) to show your proficiency (hint: the majority of Rails devs I
know don't have any OS work to show)? I guarantee this will trump all the "X
years experience" requirements and give you a legit shot at all these jobs.

~~~
BrandonM
> Why not spend a couple days becoming proficient hacking together a couple OS
> projects (or contributions) to show your proficiency (hint: the majority of
> Rails devs I know don't have any OS work to show)? I guarantee this will
> trump all the "X years experience" requirements and give you a legit shot at
> all these jobs.

That's a great suggestion. But why does no one put that in the requirements?
"Fill this arbitrary criteria -OR- show us that you're a good programmer."

There's even a problem there in that if you've been working with a security
firm or just in internal software for long enough, it can be impossible to
show all the amazing shit you've done. Everything is "For an extra-good chance
at getting hired, show us your GitHub and StackOverflow presence." If we want
to get paid, it seems we first have to be willing to work for free. For those
of us who have been out of college for a few years, are paying back $60K in
debts, and have settled into a soul-sucking tech job that leaves you wanting
to nap in the sun by the time you get home, it can be hard to break out of the
cycle.

What I'm really saying is that "the Ruby jobs out there" should in actuality
be "the programming jobs out there. Oh, and we happen to use Ruby, but since
you clearly understand analogous languages, that shouldn't be an issue."

~~~
JangoSteve
It's worth noting that when you submit your resume/cover-letter/application
for a job, it goes to 1 of 2 people. It either goes to some administrative
assistant whose sole job is to filter through all the resumes that don't meet
some arbitrary requirement (simply a function to arbitrarily cut down the
number of resumes they actually have to read). Or it goes directly to the
executive hiring for the position. If your resume makes it to this person,
pretty much nothing is set in stone (including their own requirements).

Case in point, when I first graduated from college, I landed an engineering
job that had "10 years industry experience" as a hard requirement.

~~~
BrandonM
Thanks a lot for the data point. I guess the real lesson is to show an
interest in and affinity for a position and just apply for it, requirements be
damned.

~~~
jacquesm
I got my first job in programming by simply applying to _every_ IT job at a
company where I worked in the mailroom.

Because it was an internal interview they had to do it (some kind of rule they
had to follow) and finally they gave up and gave me a chance with the testy
remark that if I failed they never ever wanted to see my face again.

Worked fine :)

------
xiongchiamiov
When I first used Rails, I was frustrated by two main things:

* Files everywhere! I like starting simple, and you generate all these folders with things I just don't want to deal with yet.

* Lots of things were implicit, making it difficult for a newbie to the framework to understand the flow (How do we get from the controller to the template? was one, I think).

Now, that was several years ago (a little over 3, now), and both Rails and I
have changed. I've been waiting for Rails3 to give it another chance, but
haven't found the right project yet.

My current gripes with Rails are this:

* DHH is a prick.

* It's damned difficult to find a good Ruby feed that doesn't get polluted with Rails stuff.

My first issue is, of course, not very valid, but I have to admit that it
exists.

For the second one, yes, I program in Ruby (and love it!), but I'm not using
Rails. Even when I do web development in Ruby, it's with Sinatra. So, I don't
want to see your frackin' "Ruby tips" that are actually Rails tips!

</endrant>

------
angrycoder
I think the problem with MVC web frameworks in general is that it makes it
makes the easy/boilerplate stuff really easy, but the hard stuff harder. Sure,
if you doing a simple CRUD app that is only updating a single table it is
fine. Beyond that, you waste so much time trying to figure out how the
frameworks wants you to represent composite objects, and debugging the default
model binders, then thinking you might have to write your own binder, then
just saying screw it and reverting to Request.Form[] and parsing your own
requests.

~~~
joe_the_user
I absolutely agree that a complex, n-table, n-page site does not scale with
MVC in general. Simplistically, [n-tables] X [n-pages] = n^2 controller
methods for n controllers. So trying to make the controllers nice and OO just
means each controllers complexity expands excessively.

I would be really curious. What pattern do people think scales in this general
situation?

~~~
generalk
In the simple case, Rails likes you to have seven controller methods and one
controller per table. Realistically I usually end up throwing a few more
methods on each controller.

This is actually part of the reason I like Rails: it guides the developer
towards what I consider to be better application design. I understand that a
lot of folks don't agree, and that's cool for them, but I still like hearing
why.

~~~
angrycoder
I can see that working if each of the 7 tables was their own individual
entity, but I am talking about a composite object here. Normalized data.

How do you manage a transaction across 7 different controller methods?

I am not saying their isn't a nice way to do this, merely using this as an
example of why people may not like Rails. It forces you to figure out the
Rails way of doing things. And that may not always be the best way for you,
especially if you are an experienced developer.

~~~
johnbender
You're describing a problem that arises as a consequence of using an ORM, any
ORM, which is not at all Rails specific.

~~~
angrycoder
when you have to spread your updates across 7 different controller actions
(methods) to make it work the Rails way, it most certainly is a rails problem.

~~~
vowelboy
You're assuming that there is a hard coupling between Controllers and Models.
There isn't.

Rails suggests a CRUD pattern, but doesn't enforce it. You can quite easily
(and elegantly) update 14 different tables from one form, using one request
and one controller method.

~~~
generalk
_You can quite easily (and elegantly) update 14 different tables from one
form, using one request and one controller method._

You can very transparently do it with ActiveRecord associations, so that
you're operating on only one instance of a model, or you can do it very
opaquely, where you instantiate and update several models. Or you can just run
an UPDATE statement; those haven't gone away.

------
davidw
I think Rails is great, and it hasn't ruined any of my projects.

Once in a while, however, the magic can be a bit tiresome - you have to _know_
a lot of things. For instance that if you change the routes file, it may make
a series of functions named in a certain way to appear in your views. Or just
how to name everything in the right way to make Rails happy.

Often times it's a time saver, but once in a while you kind of wonder if it
has to be quite so magic.

Also, sometimes those things are dynamically put together, so you can't grep
for them in the source code.

~~~
msie
_you have to know a lot of things_

 _sometimes those things are dynamically put together, so you can't grep for
them in the source code_

I completely agree.

Also: the rails guides are helpful, but the generated api docs suck.

------
timruffles
I really like Rails - for all the CRUDish apps of the world there's nothing
better: you'll avoid reinventing a lot of boring wheels.

Perhaps the reason some HNers are Rails-phobic is that Rails is rightly
designed to be precisely the opposite of tool you want for hacks: convention
over configuration, config opaquely doing as much as possible for you, and
development being as far as possible snapping together canonical bricks
(Devise, WillPaginate et al).

If it didn't get in your way for hacks with very different requirements to the
apps Rails was designed for, it wouldn't be doing its job. Right tool for the
job, as ever!

------
parfe
I don't want to be surprised by a framework.

<http://dev.rubyonrails.org/ticket/10919>

The above bug report (while incredibly funny) was a symptom of what turned me
off while learning rails. Why would tables be pluralized automatically? A
model might change to a word I didn't even know is the correct plural. ( I
didn't go any deeper than tutorials. )

Overall I prefer Django as nothing comes as a surprise, and the shortcomings
aren't a huge bother for what I do.

~~~
generalk
_Why should be tables be pluralized automatically?_

Because that's frequently how you'd do it anyway. I deal in a lot of legacy
data stores, and I have a lot of "set_table_name" calls.

That said, Rails is opinionated, and not agreeing with those opinions seems
like a perfectly valid reason to not like it.

------
kreek
Some issues I think come from the early hype that it was the 'one framework to
rule them all'. I personally love Rails but it is a bit heavy and shouldn't be
used for smaller projects. But that's not Rails fault it was more a
misunderstanding of Rails' sweet spot. For those smaller projects I now use
Sinatra.

That said when I first started using Rails, four years ago, it should have
come with a warning sticker about deployment issues. A smaller VPS that could
handle dozens of PHP apps could be only really handle one maybe two Rails
apps. Litespeed, Passenger, JRuby, etc. have made these issues go away, but I
can see how it might have left a bad impression of the framework.

P.S. You think people hate Rails try being a Flash developer on here.

------
almost
Some people don't like Rails. This isn't a problem. It's not a personal insult
to you or to your skills or to anyone else who likes or uses Rails. It's
sometimes useful to discuss the limitations (in some subset of people's views)
of software.

I say this as someone who quite likes Rails but doesn't use it at the moment.
It just so happens that the bit of web work I do at the moment tends to fit
Django better. But don't worry, we don't need to hate each other :)

I've flagged this article because I really can't see anything of worth coming
out of it. Holy wars are very rarely that interesting.

~~~
generalk
My intent wasn't a holy war.

I've used Rails for over a year. I keep hearing people say that it's slow, or
it doesn't scale well, or that after the first 80% of the application is
finished it gets in your way.

I haven't found that to be the case, but my experience is limited. So I'm
looking for any cases where any of these things have actually happened. I want
to know if these claims have any substance.

~~~
almost
Of course there are cases where Rails isn't the right solution, that's true of
absolutely everything. It's probably fine for all your uses (and for mine too)
though. You are not going to get a useful discussion of them with that blog
post though. You use an antagonistic tone and target a group of people who
largely only exist as a group in your head, that's not going to produce good
stuff!

------
Pewpewarrows
I'm pretty sure the general direction of the comments weren't bashing on Rails
specifically, just the idea that they thought the honeymoon wouldn't end (it
always does).

They went from a very heavy django background, where they saw the shortcomings
of the framework (or every framework, really), dabbled in Rails for a day,
loved its magic for trivial tasks (protip: most frameworks make trivial tasks
easy and magical), and somehow concluded it was superior to django and that
they had stumbled on a hidden gem (pun intended).

Frameworks have limitations. You will always reach a point in your career
working with them that you disagree with one or more design choices, and you
will have to deal with a problem the developers never accounted for. Sometimes
that problem is easy to solve using your existing framework, and sometimes the
framework (in solving 95% of other use cases) makes handling and solving that
problem a pain in the ass. It isn't unique to django, Rails, Zend, or whatever
else you happen to be using. But pretending that the framework you just
discovered is perfect is just silly. Take the language you enjoy working in,
find a framework that suits your style and doesn't get in your way too often,
and run with it.

My apologies for still giving vague, sweeping statements, but I haven't worked
deep enough with Rails for it to get in my way yet (I've only done a few
simple proof-of-concept sites with it).

------
jamesbritt
I preferred Nitro over Rails when they both arrived in 2004. Nitro made it far
easier to evolve an application from a single static HTML file to any degree
of complexity (plus it was faster, thread safe, and more modular). Rails
seemed better suited to a very specific genre of application. Great when
you're building that app; less so when you needed to color outside the lines.

Ramaze picked up where Nitro left. All software is opinionated; I prefer the
opinions built into Ramaze. Whatever tool you pick, whatever language you use,
make sure the opinions it embodies align with yours, or you'll find yourself
frustrated way too often.

But I really think the alleged hating on Rails has more to do with how some
people perceive its more vocal proponents. Sadly, it all feels like being back
in high school again. It's the "rock star" and "hero" nonsense that grates.

People would do better to scope out the various languages and tools, learn to
appreciate the good stuff, steal the better ideas for their own preferences,
and ignore the personalities and drama.

Code talks, bullshit walks.

------
bensummers
I moved away from Rails because the data model didn't fit my app. But I still
use it for all the management applications.

Here's a writeup I did for EngineYard about the move from Rails to JRuby and
my own app 'framework': <http://bens.me.uk/2010/jruby-in-practice>

~~~
generalk
Fascinating. I'd love to hear about the data model mismatch -- having done
mostly CRUD webapps, I'm not really in a position to see that.

~~~
bensummers
Well, the main problem is that the user data we store is multi-valued. So each
attribute can have multiple values in the same 'record'. As you can imagine,
Rails doesn't help much in this situation, as it assumes that each column in
the databas table has just one value.

<http://www.oneis.co.uk/technology/object-store>

Oh, and each application on a multi-tenant app server can have a completely
different schema. Again, there's not much that Rails can do to help.

Rails was good to get going, and it helped for the relational stuff in the
app. But unsurprisingly, if you try and use it for something it's not designed
to do, it's not going to work terribly well. This principle applies to
everything.

------
jamie_ca
I first experimented with Rails in the 0.7 days, and stuck with it until
sometime in the early 2.x series. The general complaint you mention about "it
got in my way and I had to abandon it" is basically at the top of my list.

As Rails evolved, it picked up a _lot_ of cruft, and when things went subtlely
wrong (or I was trying to track down a "magic" method) it was just a big pit
of morass to dig through. About that time (nearly 3 years ago) I switched to
Merb, the new kid on the block. That's had its own share of pain to deal with,
and at work we're now figuring it'll be worth it to migrate back to Rails 3.
The Rails/Merb "merger" has resulted in a lot of good architectural cleanup,
and being able to live within the regular plugin ecosystem has a lot to say
for it (namely, we won't need to maintain the dozen-odd forks for merb support
anymore).

------
keefe
>it's completely won me over, replacing almost every single place I'd use PHP

which it should, php is terrible. It's OK for many purposes, but there aren't
that many spectacular libraries for difficult things, lack of sophisticated
IDE support, etc.

~~~
jacquesm
Some HN'ers seem to hate PHP, I want to know why :)

I couldn't care less about a platform someone else uses that I don't use.

Familiarity breeds contempt. So I think I'm qualified to rant on PHP because I
wrote an awful lot of it over the years and am still maintaining one large PHP
project that was written in the PHP2 days, so you can imagine what that's like
(we're re-writing that at the moment).

If you're happy with rails, more power to you. If you're happy with python,
great!

Whatever you use, if you're happy with, I'm happy for you. Meanwhile, live and
let live.

So, PHP may be 'terrible' for you, but it has made me more money than all the
other programming languages that I know _combined_ , in spite of all its
shortcomings.

Spectacular libraries for difficult things? Not on my wishlist. Lack of an
IDE? I use vi(m).

It's all just work, and work needs to be done. Use the tool that's best for
you and move on, don't look back too much and kick at where you came from.

And if you didn't 'come from there' you shouldn't be having an opinion on the
subject anyway, then you're just parroting.

~~~
fragmede
PHP has a long documented list of shortcomings, but y'know what? Just like
shell scripts, it is absolutely fantastic at small one-off but long-lived
programs.

~~~
jacquesm
> it is absolutely fantastic at small one-off but long-lived programs.

Like facebook? ;)

------
hasenj
Frameworks have limits, the same guys who loved rails had a previous
experience with Django where they loved it then they hit a wall and started
replacing all of its components.

Of course Rails is 100x better than php.

I suspect it exhibits the same characteristics of frameworks that make a lot
of people turn against Django after some time. It is, after all, an
_opinionated_ framework.

If people never hit a wall with it, I'd be a bit concerned; perhaps they're
probably not trying hard to push their apps beyond limits of the framework.

------
DanielRibeiro
Avi Bryant answered this here
([http://python.mirocommunity.org/video/1186/django-is-
obsolet...](http://python.mirocommunity.org/video/1186/django-is-obsolete-but-
so-is-e)), but on Django form. For the projects he mentions, sinatra is more
than enough.

------
nlz1
"7 reasons I switched back to PHP after 2 years on Rails"

[http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...](http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html)

------
jcapote
There's a major python slant here. I don't know why, but it always feels that
way to me as a regular reader here.

------
atldev
I think this is a great question to ask. I feel the same way, and unless I
missed it in the comments so far, I don't see any specific examples that would
give me pause.

I'm loving Rails so far, especially after being able to start from scratch and
build a viable, working, commercial, revenue earning app in just a week. I'm
sold, but scanning the horizon cautiously.

~~~
nlz1
[http://blog.leosoto.com/2008/12/on-really-disliking-
monkeypa...](http://blog.leosoto.com/2008/12/on-really-disliking-
monkeypatching.html)

------
PhrosTT
perhaps the theory is one day your site will blow up and you'll need to
scale... or hire additional programmers. at which point these things are
probably easier with a php app...

there's a certain safety in choosing the more popular language.

------
peteforde
My two guesses:

\- more job opportunity at higher billing rates for Rails

\- it's easy to hate on smug people, unless you're on their team

I'm perfectly happy with Rails, because we've now invoiced several million
dollars on cool projects that we never would have worked on had we stuck to
[in our case, .NET].

------
joe_the_user
Every system I've seen that has some "magic" also has the potential for that
magic to reverse itself and become something that seems to work against you.
And when that happens, it's easy for the magic to become something you "hate".

Rail and Ruby each a lot of this magic.

No matter what you say, Twitter is relevant. No matter what Twitter says,
Twitter is a Rails _success_ story because Rails got a major, major site up
and running fast. And naturally when the magic stopped working, everything
about Rails just seemed to work them. It was what they needed until they grew
into a site that wasn't well served by Rails.

Imagine if I said, "San Francisco is a terrible place to start a business and
what proves it is that we experienced wild success and then couldn't rent any
more office space, had to split our headquarters and eventually moved to
Omaha". How convincing is that?

