Some HNers seem to hate Rails. I want to know why.
joncanady.com
joncanady.com
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?
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.
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."
Case in point, when I first graduated from college, I landed an engineering job that had "10 years industry experience" as a hard requirement.
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 :)
For me it's different. It takes me a long time to really know a framework (and a language too), the up-front cost is for me ridiculously high and so is the cost of switching.
I take a huge hit in productivity as soon as I hit another language and it takes me quite a while before I'm back up to speed.
I'm 'old school', as in I don't use an IDE, I pretty much memorize the documentation and by the time that I think I'm fluent on a platform, I usually really am.
For you that's obviously different, so don't rant, go and spend that time and you'll be fine.
The point is that many companies have sightly different stacks. Your company wants a programmer fitting X criteria... I go fulfill that on my own time while I'm working another full time job, applying to other jobs, and trying to develop personal projects because everyone wants those now too and you then decide that I'm not a good fit, and I get to go do it all over again. Of course it eventually converges as I learn how to build a blog 20 different ways, but why not treat programming jobs more like apprenticeships? The way it is now only makes sense for people who are happy to spend 12-16 hours a day in front of a computer contemplating technology.
> For me it's different. It takes me a long time to really know a framework (and a language too), the up-front cost is for me ridiculously high and so is the cost of switching.
It's like that for everyone because we're forced to wrap our head around a bunch of seemingly-arbitrary design decisions in a solo quest of technology dominance, with haphazard how-to posts and incomplete documentation as our guide. How much easier would it be to learn a company's technology stack in the context of the work you'll be doing, with the guidance of someone who's already working with it?
> For you that's obviously different
Not exactly. I just think the entire setup right now is grossly inefficient and requires a bunch of otherwise valuable employees to bang their head against a wall for a while before anyone will give them a real shot.
The problem companies face is that the real traits of good developers are difficult to evaluate in the interview process. This is why tests (both generic programming tasks and a few 'real-world' problems) during the interview are important. Yes, I hate having to do them, but I recognise their importance. I'm very wary of an interview for a development position that doesn't involve a test at some point.
People hiring for development positions: languages (particularly the new trendy ones) aren't particularly important - a good developer will be able to learn enough in a short time to essentially hit the ground running. Hiring a bad developer who knows (or at least manages to convince you that they know) your favourite language / framework is going to cause you endless headaches.
We've been doing a ton of interviewing recently, and when it comes down to it I don't care one bit what you know or how long you've been doing it. All I care about is: 1) how well can you code, 2) how willing are you to learn new things, and 3) what's your style/personality like.
Maybe you need to ignore those job postings and find the ones that get it. They're out there.
Also, while I haven't done much OSS work, many of my friends are quite active and they have job offers pouring in from everywhere. Consider building something useful, and then throwing the code up on github (w/docs please!).
Actually, it's kind of funny, I just tweeted this yesterday: http://twitter.com/shiftb/status/24434467285
Edit: [1]What languages/frameworks you know.
* 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>
I'm looking for concrete Rails-specific issues. I understand that, in theory, Rails may suffer from this issue. In practice I've never once seen it.
I think Request.Form is an ASP.NET thing. I have no experience there, so I can't comment on it.
I would be really curious. What pattern do people think scales in this general situation?
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.
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.
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.
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.
The problems only when things go past averageness in one way or another. I actually have had more problems with Rails in personal apps I wanted to develop than in apps for clients.
Rails is a paradox - the bleeding edge framework that works for only non-bleeding-edge sites...
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.
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.
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!
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.
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.
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.
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.
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.
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).
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.
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
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.
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).
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.
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.
Like facebook? ;)
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.
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...
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.
there's a certain safety in choosing the more popular language.
- 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].
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?