

Thank you, Rails - jacobian
http://jacobian.org/writing/thank-you-rails/

======
jon_dahl
This is the tone that every language/framework comparison should take. Thank
you, jacobian!

~~~
iamelgringo
The django core devs are one of the best thing the framework has. I'd have a
beer with any of them at the drop of a hat.

~~~
subbu
You made me google for Django core team just to make sure I remember all of
their names
[http://docs.djangoproject.com/en/dev/internals/committers/#t...](http://docs.djangoproject.com/en/dev/internals/committers/#the-
original-team)

------
andrewvc
This article is spot on.

It's a tribute to Rails' genius that so many people view it as a threat. You
still see people who seem genuinely afraid to let go of their massive, overly
complex frameworks, or optimizing every little bit of their PHP app. People
afraid of relinquishing the slightest bit of control for convention.

What I actually see, when I hear developers decrying this stuff, is geeks
afraid that they're going to lose their Genius cards now that there's an
easier way.

The fact is, Rails doesn't reduce the amount of hard thinking required to
write a reasonably complicated web app, it reduces the amount of boring boiler
plate code. For heavy lifting Rails still gives you the tools you need,
there's a reason Rails Metal and find_by_sql exist. There's a reason most of
the core parts of Rails are interchangeable (esp. with the upcoming Rails 3).
Solving any worthwhile problem generally requires real work. Rails doesn't
change this.

The brilliance that Rails brings to the table is balance. Many of the design
decisions of Rails just hit the sweet spot for a large category of apps, and
remove so many of the pain points in development.

~~~
dasil003
I sort of agree, but you're coming off a little over-excited there, and I say
that as a 5-year Rails developer.

The thing about Rails is that it represents the maturation of web development.
It's not anything amazing per se, just a clever roll up of the best practices
that emerged from the decade of Perl, Java, PHP development that preceded it.
Ruby is the secret sauce that makes things just feel so slick.

I don't mean to minimize the initial innovation, it's just that Rails is no
longer very unique. A lot of frameworks have largely caught up even if written
in less flexible languages, and long term I see opportunities for new
frameworks to leapfrog Rails.

The biggest liability for Rails is the Ruby runtime. Yes progress is being
made here, but it's still a pretty sad state of affairs with regards to memory
leaks and performance. I bang my head up against this every few months and it
really hurts.

Another issue is the need to handle more complex applications. Frameworks like
Seaside allow you to set up complex stateful apps in a more robust way than
will probably ever be technically possible in Rails (again due to limitations
with Continuations in the Ruby runtime).

A related issue is the question of what dark places we will end up in over a
couple decades of large code bases running under Ruby with no warnings. I
think it's pretty clear by now that Java is an unnecessary straitjacket, but
do-whatever-the-fuck-you-want-with-no-warnings-whatsoever Ruby environment is
not necessarily the most conducive to long term stability. I'll take it over
Java any day, but I still have my doubts.

Finally, there is the issue of increased ajax-ification of apps. Rails was a
leader here early on insomuch as it provided proof of concept that Ajax could
be done easily without a cross-browser-DHTML-guru certification, but 5 years
later the Prototype + Rails helpers paradigm is quite dated. Ajax has huge
potential for simplifying back-end code and making web apps inherently more
scalable and performant. This is one area where Rails could re-invent itself,
but a mature framework like Rails is going to have a disadvantage against a
fresh approach starting from first principles.

In short, I think the competition has openings.

~~~
patio11
I love Rails to death and do Big Freaking Enterprise Web App Development in
Java all day.

A lot of what people identify as pathological is an evolutionary advantage in
BFEWAD. Straight-jacketing the programmer is often a good thing because on a
team of 100 programmers in three continents (you might think I exaggerate),
including (by my last count) 12 programmers who have less than 3 months of
professional experience, we want to make sure the damage done by the least
skilled programmer on his worst day is strictly contained.

I don't know if Rails scales to that sort of development, to be honest. The
least skilled developer, touching one part of one class at the periphery of
the project, is essentially one line of code away from blowing up the entire
project.

I should know: since I'm the sole Rails programmer at my business, I am by
definition the least skilled programmer. And since I've managed to corrupt the
results of my analytics code by making a one-line ill-considered addition to
my printing code (which are kept in wildly divergent classes in different
packages and namespaced from each other), just because it was not obvious I
was altering the global state of the interpreter. That sort of bug has never
happened to me in Java.

A lot of techniques which are considered kosher in the Rails community don't
scale to large distributed teams really well. Monkey patching is the obvious
example -- if you have two developers who have different understandings of
what Array#pack is supposed to do, you're going to run into HELLACIOUS,
difficult to debug bugs. If you do not quickly clue into the fact that
Array#pack was redefined in a file you've never seen before that was committed
last Tuesday by your most junior developer in the Seoul office, enjoy spending
the next several days going over code you swear looks right looking for the
error.

~~~
raganwald
_I don't know if Rails scales to that sort of development, to be honest_

Waaay off topic, but i wouldn't use the expression "scales to." Asking how to
scale Rails up to 100 programmers is asking the wrong question. Asking how to
maintain the same application with just one team on one continent is the
question and Rails might be the answer. Then again, it might not be the answer
for your specific company. But that is the question to ask.

 _If you do not quickly clue into the fact that Array#pack was redefined in a
file you've never seen before that was committed last Tuesday by your most
junior developer in the Seoul office, enjoy spending the next several days
going over code you swear looks right looking for the error._

Again, you have my sympathies. But Rails is not the answer to this problem and
neither is Java. One answer to that question that has worked for others in
this situation could be continuous integration. Why didn't your automated
tests fail when the dev in Seoul checked his code in?

I am not saying Rails is for you, or for anyone with 100 devs on multiple
continents. But I do have a little experience with multiple developers on
separate continents building C++ and Java applications, and the problem of
stopping developers from breaking code was always solved with processes like
continuous integration and code reviews and not because of some special
property of Java.

I like Rails for certain things and not for others. I am not arguing you
should use it. But I do feel that the issues you raise are not Java vs. Rails
issues but process issues. Java won't solve them for you and neither will
Rails.

~~~
rbanffy
"Asking how to scale Rails up to 100 programmers is asking the wrong question"

Just imagine what we could do with a Beowulf cluster of 100 Rails programmers!

~~~
ptomato
In Soviet Russia, Slashdot flashbacks to you!

------
kevinholesh
This is exactly the kind of attitude I like to see. Rather than argue why a
certain framework or language is better, I'd rather reflect on how much things
have changed. I remember 5 years ago programming in object oriented PHP.

I'm much happier now with Rails and Django.

~~~
Jim_Neath
I hear that.

I spent nearly 4 years doing OO PHP. I enjoy coding a lot more now I'm rocking
ruby/rails.

If anything this article has made me more inclined to check out python/django.

------
blasdel
The Rails novelty I've been most thankful for is their initial popularization
of the use of non-monolothic web servers. Every webapp running on your machine
doesn't have to be served up end-to-end by a single Apache config, much less
with your goddamn programming language runtimes linked in to the same binary
-- but nobody seemed to know that at the time.

Yes, there was plenty of emotional bullshit in the community as solutions were
hyped and abandoned. I think Passenger was initially a massive logical
regression when it was _mod_rails_ , but now that it's _mod_rack_ it no longer
agitates me so.

Thank you, Rails, for helping the world realize how awesome HTTP is as
seamless, simplifying middleware.

~~~
dasil003
I dunno man, for most of the apps I run (2k-10k lines), the memory requirement
is usually the biggest pain point.

~~~
blasdel
No doubt, MRI has the worst GC of any programming language implementation in
active use today, and the design of ActiveRecord/ActiveSupport/etc. push it
over the cliff.

Even if it mostly failed at pulling it off, Rails convinced even some PHBs
that Apache is not the alpha and omega of HTTP.

------
dannyr
jacobian is on fire with his blog posts lately. However, what he said that
"Windows folk look down on us Mac users" is in my experience false. It is
definitely the other way around.

~~~
amoeba
It goes both ways and I'm not sure one side is guiltier than the other.

~~~
rimantas
My impression is that Mac users tend to look down on Windows—the OS itself not
its users, while liking Apple products makes you douchebag, sheeple and
brainless victim of Apple marketing. Maybe that's because the most of Apple
users do have experience with MS products which is not always the case on the
opposite side.

~~~
bad_user
That's not my impression at all.

Truth is, people can get kind of religions about their technological choices,
no matter what those choices are (I guess it takes some faith to believe in
your choice, when there's no clear answer to "which is best"? ... there never
is).

------
10ren
The "love or money" struck a chord. It's similar to "when your hobby becomes
your job, you no longer have a hobby." It certainly adds new concerns. There's
the finding that rewards can be _demotivating_ :
<http://www.gnu.org/philosophy/motivation.html> (HN:
<http://news.ycombinator.com/item?id=783939>)

There's pg's idea, of working hard to make lots of money, so you are free to
work on what you really enjoy.

And 37Signals' idea, of a lifestyle business that you enjoy working at in the
first place (assuming you resolve the above added concerns and demotivation).

------
marknutter
I love this post. I've only recently gotten into development (< 3 years) and
my biggest complaint about the development world is all the fighting between
languages, frameworks, etc. I credit Rails with being the reason I was able to
get into development in the first place - it made web development extremely
accessible to people like me with little to no app development experience.

So all that said, I really appreciate the author's candor. The negative
attacks people make against other frameworks and languages really discourage
people who are just getting started with this stuff because it casts doubt in
their minds about whether or not they bet on the right horse. I may actually
play around with Django now to see what it's all about.

------
nopal
This attitude is one reason that I really like the Django community. I've
found, almost without fail, that most Djangonauts are friendly and patient
with the framework's users, new and old alike.

~~~
carbon8
Yeah, friendly with django users, which is nice if that's all you are. The
problem, however, is what he mentions in the post: _"I’ve noticed the tone of
the arguments in the Django community getting nastier — especially when it
comes to Rails."_ Hopefully the ideas in this post catch on and I'm glad a
prominent Django developer is calling it out.

I mentioned Ian Bicking's great talk at this year's PyCon elsewhere in these
comments, but another thing he touched on was framework fanboyism, and how
it's mainly the result of people being new to the framework and trying to
convince themselves that it's the answer to everything. Whether it's Django or
Rails or any other technology, excitement is good, but not when it becomes
tribal and adversarial toward perceived competitors.

------
eam
I liked the civil approach!

------
mattjaynes
My first thought when reading this is "The Django guys even think about
Rails?"

I don't know much about the Django community, but in the Rails community I
seldom hear any discussion of Django. The few times I've heard talk of Django
in the Rails community, it's along the lines of "Oh yeah, it's great for x/y/z
use cases." It's hard for me to imagine DHH or other Rails notables writing
anything remotely similar to this post.

Is this just me being sheltered? Or is there more of a pre-occupation with
Rails in the Django community than vice-versa? If so, why? Just curious to
hear what other's experiences have been.

~~~
bad_user
I don't know much about the Rails community, but they should definitely look
at Django.

Django currently is more modular. The ease with which you can integrate third-
party components is unparalleled in my experience. I also like Django's ORM a
whole lot more.

Rails is awesome, other frameworks are too ... but keeping blinders on is not
good on the long term.

~~~
carbon8
Rails borrows plenty from django and python at large. Merb's slices and Rails'
engines were directly inspired by Django's apps. Rails is getting automatic
escaping of strings in templates after Django showed it was a better default.
Rack was directly inspired by WSGI. Rip is based on pip. Rails developers
aren't "keeping blinders on." Exactly the opposite.

------
clutchski
In addition to the cultural shift it brought to the web community, Rails' is
due a debt of gratitude for its technical innovations as well. Django, Merb,
Pylons and others are all iterations on the Rails approach to web development.
Django, it seems, is like a teenage boy nearing the end of his adolescence and
realizes that just maybe his parents aren't as stupid as he once thought.

~~~
jdunck
FWIW, Django was in private use before Rails was made public, so while Django
and Rails are kindred, it's not reasonable to call Django an iteration of
Rails.

~~~
clutchski
good to know. thanks.

------
sailormoon
Excellent article!

