
Ask HN: State of Django vs. Rails? - argonaut
I always like to keep tabs on the state of different competing frameworks. Any thoughts on the current state of Django vs. Rails? Especially with the upcoming Django 1.5 and Rails 4.<p>Some factors to consider beyond just the design of the frameworks: productivity, readability, documentation, activity of community, tooling, ease-of-use/learning, etc.<p>I've purposely left out node.js and its associated frameworks (Meteor, Derby, etc.) because AFAIK the field is still wide open and node.js has different use cases.
======
jacobian
Obviously I'm totally biased and you shouldn't listen to me.

But if you _were_ to listen to me, I'd probably be saying something about how
they're basically equivalent these days. Both are pretty productive, have
clean readable code, are well-documented, have active communities, a wide
array of plugins and tools, and are fairly easy to use.

If you were to get even crazier and try to get some advice on which you should
use, I'd probably tell you that Rails is best if you already know Ruby; Django
if you already know Python. If you don't know either, take a week or two and
build a site with both and see what sticks. Either way you'll be pretty happy.

But you shouldn't listen to me because I'm heinously, terribly biased, so you
probably didn't hear me say any of that. Just as well.

~~~
rednukleus
> If you don't know either, take a <em>week or two</em> and build a site with
> both and see what sticks.

If only we were all this talented.

~~~
dnsauve
I don't see why this isn't good advice.

This is exactly what I did when I was trying to decide between the two. It
really doesn't take long to work your way through the introductory tutorials
to get a feel for which framework and language you prefer.

~~~
rednukleus
I've been learning Python and a bit of Django, and it has taken me a lot
longer than 2 man-weeks to get to grips with it. I can't imagine that I would
be able to learn enough Ruby to give Rails a good shot in two weeks.

I'm absolutely sure that there are many developers out there that can pick
these frameworks up that quickly, but I'm equally sure that there are plenty
of developers who "aren't that talented".

~~~
dylangs1030
I don't want to sound pretentious, but were you coding >6 hours a day?

Languages are as much a process of thinking as they are a string of
instructions for a computer. If you think in object-orientation you'll learn
object-oriented languages _very_ fast. Likewise, if you know a language like
Lisp you'll learn man of its descendants in the same family of language
quickly.

I work full time and program when I'm not working, and I'm often surprised at
the improvements and iterations I can make in (relatively) short periods of
time. It's the same way you can become fluent in a spoken language in 3 months
[1]. Talent isn't relevant after the first week - raw determination is.

That said, you're right, you shouldn't _expect_ to be a capable programmer in
a language after just 2 weeks, but don't be so hard on yourself that such an
accomplishment is impossible.

[1]: <http://www.fluentin3months.com/>

~~~
rednukleus
By man-weeks I mean 40-60 hours effort per "week". I think that some
developers can "learn Django in a week or two from scratch", but I don't think
most newbies can.

~~~
nobleach
Well for newbies coming to the table, there sure are a lot of concepts they'll
have to pickup. Same for PHP developers. In all of these frameworks, there is
the concept of routes, data models, views/templates, controller actions, etc.

So learning one framework definitely helps out in others. The biggest hurdle
for me (coming from Perl CGI then PHP to Java 10 years ago) was that I was no
longer accessing a "page"... I was accessing an action in a controller. I
could use views as a template and REUSE those views for other things. The "one
page for each action" paradigm became dumb after that.

Most newbies can fight through the demo "blog apps" rails/django tutorials and
still have no idea what they're doing. But doing them multiple times until one
is comfortable with the pieces is probably more beneficial.

Lastly. Learn the actual language. I love Ruby because it's a joy to use. I
hate Python. It's not a bad language I _PERSONALLY_ don't enjoy it. So Rails
was a no-brainer. I enjoy Scala, so Play Framework was a no-brainer. I (I'll
admit) have fun writing Javascript, so Node.js with Express.js is fun to
write.

------
beatpanda
I prefer Django for the same reason I prefer Python — Django is more explicit,
there's less 'magic', and it's easier to figure out what's going on when
something goes wrong.

One example is model definitions — in Django, the canonical definition of a
model's database schema is in an app's models.py file. I'm still not sure
where to look for this in Rails.

Additionally, other tools you decide to use with Django don't require any
extra "Django magic" to work — they work the same as they would if you used
them alongside any other tool.

One example is using Less with either framework. Using Less's `less.watch()`
functionality, which enables live updating in the browser based on changes in
your .less file, is much more difficult to use in the Rails asset pipeline, in
my experience.

There's pretty much feature-for-feature parity at this point, and where it
doesn't exist there's a plugin or other supplemental tool. For Django, pip,
south, and django-mediasync cover for bundler, migrations, and the asset
pipeline (sort of). And of course there's a rails admin gem.

But these are the same tradeoffs that have always existed, and I don't think
any of them have changed in the new versions.

~~~
jarrett
> canonical definition of a model's database schema...I'm still not sure where
> to look for this in Rails.

db/schema.rb has that.

> Using Less's `less.watch()` functionality, which enables live updating in
> the browser based on changes in your .less file, is much more difficult to
> use in the Rails asset pipeline, in my experience.

I have found that to be difficult too. It think it's because Less has fallen
out of favor, and SCSS is the new standard. It's actually super easy if you're
willing to use SCSS.

You mentioned Django plugins providing an asset pipeline. Do you feel that
it's easier to start supporting a new asset type in Django's pipeline than in
Rails'?

~~~
nobleach
It's not user defined in db/schema.rb. When using migrations, the schema is
written to that file. It's entirely possible to bring a legacy database to the
app and never create a migration. Rails just reads the table definitions from
the database.

I think the schema.rb file CAN be used to build the database though... I'm
trying to remember. I feel like I've done that before.

This is good and bad. Good because it saves the developer from describing
something that's already described in another area. Bad because it takes away
a bit of control.

My Django apps had a bunch of legacy tables that I was forced to sit and
document. I had to remember to go back and add another line every time I added
another field. But, to be honest, it's pretty much the same way with most
other frameworks I use.

~~~
jarrett
> When using migrations, the schema is written to that file.

You can also run rake db:schema:dump at any time. So it works great with a
legacy database. You don't need to run any migrations for this to work.

------
ersoft
As a both Django and Rails developer I suggest you to choose Ruby on Rails.

Rails pluses:

\- Has a nice asset pipeline (automatic conversion of CoffeeScript, Sass,
Haml, Jbuilder, etc) and concatenation + mignifying.

\- Really configurable database migration with a nice DSL. (Django has South
which auto generates migration files, but It isn't just as easy to change
them)

\- Rake tasks (Django also has management commands, but It's easier in using
rake)

\- multiple environments (development, production, testing), being able to
store different configurations (Django does not have this, you can achieve
this using some hacks)

\- Railscasts.com (great screencasts by Ryan Bates)

\- Better release circle, as long as I know in Django didn't appear many
features since 1.0 (mostly bug fixes and Python 2.x deprecation warnings)

\- more OOP than Django, it really follows MVC pattern, Django is a MVT (Model
View Template framework)

\- More libraries and more complex and configurable than django libraries.
Most Django libraries handling authentication stick on default User class, so
it's difficult to subclass it if you require custom fields.

\- Model hooks and scopes (I know django has model hooks but they are built
using Django signals, not using nice DSL as in Rails)

\- Concerns inclusions which guides you to a clean coding style.

\- Controller before_filters (very useful when you want to run a filter before
multiple actions, eg: check if user is logged in), I know it can also be done
using Django middlewares.

Django pluses:

\- Django admin (Rails also has a few plugins which try to implement this, but
django's is built in and also well documented in their official docs)

\- Django built in authentication system (Rails comes with devise library and
other alternatives, which is great but not built in)

\- Easier to learn (Django follows Python's Zen, "Explicit is better than
implicit.", all classes or methods you use must be imported, Rails pollutes
global namespace with all classes and namespaces imported from libraries when
Gemfile is parsed). It is easier to learn which module each class comes from
and it helps you a lot at debugging if you are a begginer.

\- Django middleware (you)

\- Form based validation (each model can be validated using form class,
another minus for Rails is that there was some security vulnerabilities
targeting mass assignment on Models)

~~~
legutierr
Much of what you say is opinion (so I can't disagree with it), but I think a
couple of your facts are off vis-a-vis Django (or at least out of date):

> Better release circle, as long as I know in Django didn't appear many
> features since 1.0 (mostly bug fixes and Python 2.x deprecation warnings)

A lot has been added since 1.0, including multi-db support, admin actions,
aggregates in the ORM (and other ORM improvements), class-based views, and
many other features that I can't think of off the top of my head.

One benefit of Django that you are leaving off your list is general stability,
in the sense that the Django team is obsessed with ensuring backwards
compatibility between major releases. My understanding is that the Rails team
is willing to break backwards compatibility with a frequency that can impact
people negatively.

> Most Django libraries handling authentication stick on default User class,
> so it's difficult to subclass it if you require custom fields.

This is changing in 1.5, the release of which is expected soon.

> More libraries and more complex and configurable than django libraries.

Honest question: how many of these Rails libraries implement things that are
implemented in the Python standard library? In other words, are there more
Rails libraries because Ruby itself is less complete than Python?

~~~
ersoft
You're right, I can be out of date, I didn't code in Django in the past year,
only in Ruby on Rails, but still I have the impression that things go much
slower on Django release circle compared to Rails

I'm glad to hear they are fixing the annoying bug in 1.5.

About libraries, Python follows the idea that there should be only one way to
do something, ruby follows the idea that there should be more ways to do
something, this is why there are a lot of alternatives, for example:

Testing: rails built in, rspec, minitest, test-unit, bacon, etc JSON
Generation for views: jbuilder, rabl Memcache: memcached, dalli

And many other gems have more than one alternative, which I think it's nice.

~~~
dgunn
> About libraries, Python follows the idea that there should be only one way
> to do something, ruby follows the idea that there should be more ways to do
> something, this is why there are a lot of alternatives, for example:...

I think you're stretching the meaning of this a bit beyond it's intent. It
applies to more low level things than testing or JSON generation. The standard
library does have a lot of excellent (and almost default) choices but it
doesn't stop people from making alternatives.

------
bayesianhorse
You don't see anything comparable to Pandas, Numpy or Scipy in Rails.

Yes, there's SciRuby, but they aren't quite there yet.

~~~
gourneau
This is a great point. I work in biotech, and we use Python because of
increasingly rich scientific tools available for Python. This makes Django (or
another Python framework) the clear choice, just because it is Python.

Think about the whole language ecosystem. Django is just Python.

SO has 165,076 post tagged for Python. Just 65,706 for Ruby.

P.S. We are hiring Python/Django devs in SF. Email me if you are looking for a
gig :) You get to work on a open source this project :
<https://github.com/iontorrent/TS/tree/master/dbReports>

------
jspiral
I've been doing a ton of work in both recently. In particular, i've been the
lead dev on a new product for web and mobile in django, an API layer
supporting an iphone app over an existing SQL server database in rails, and a
rewrite of the backend for some kiosks in rails, on top of various
contributions to other people's projects.

I want to make some comments on writing APIs in particular, since I've been
doing a lot of it lately, as my projects almost always have several interfaces
these days, e.g. native mobile apps, angular.js web frontends, and as I
mentioned above, fat clients running on kiosk hardware.

Building json apis in rails is a pleasure. My mini stack inside of rails is
controller -> request handler -> model layer + external services -> rabl. Very
clean, few lines of code, easy to maintain, does exactly what you want.

Doing the same with default django is a little less obvious. Tastypie is cool
but when you get much beyond providing CRUD over the web to your models, it
gets messy. Forget nesting stuff more than one layer deep. In the end, I build
a controller layer that matches the way rails works and it's just about as
nice, but I have to know and follow the conventions myself.

In particular, i'm copying rails style validators for models, I've built
something similar to my rails request handlers using django forms to handle
input, and i've built a simplified controller layer that handles routing,
paging, filtering, sorting, etc. Instead of rabl, I just write a to_dict
function to package data into a response. not quite as slick, but roughly
equivalent.

I had to do more on the django side to get there, but at this point both are
equivalent for me in terms of building APIs.

I understand that these days there are compelling arguments for building APIs
in neither of these languages. However, for speed of development, ease of also
putting up a vanilla web interface, and richness of the ecosystem as a whole,
I still like django and rails for building mvps.

~~~
squidsoup
I have been enjoying working with Django Rest Framework (<http://django-rest-
framework.org/>) recently. It has a less magical approach than TastyPie and
uses Django conventions like class-based views. My favourite feature is that
the framework generates a web interface, making the API browseable
(<http://restframework.herokuapp.com/>).

~~~
iends
I've used both tastypie and django-rest-framework for large projects and my
preference is also django-rest-framework.

~~~
jspiral
To both the django-rest-framework advocates:

thanks for the recommendation, will check it out. I got deep in the guts of
tastypie and wasn't happy with the way it handles patching and nested objects
in particular.

For my kiosk project, as an example, I need to send a nested object graph over
the wire. The wifi card in the kiosks isn't very reliable, so doing it in one
call is very helpful (only one thing to retry a couple times, vs 10-ish
objects, max depth of 4).

From what I can tell, django-rest-framework is read-only beyond one level of
depth (you can return a nested hierarchy, but not post it in one shot)

Also, some of my objects are transient (e.g. credit card data), so I don't
have a django model for each object that is an input to the api. (I have a
plain old python class with some special magic for parsing track data,
validation fields, etc for credit card and drivers license in particular,
can't ever save that data to the db).

would you use django-rest-framework for that?

(also, is there a django equivalent of ActiveAttr, which lets you make ruby
classes that act like active record objects without the persistence? or would
you just make models and never save them? probably wouldn't look so good in an
audit though)

~~~
iends
I actually just had a conversation at work about this (although unrelated to
Django). Almost all REST frameworks I've encountered have no support for
POSTing of nested objects.

I do not know of an ActiveAttr equivalent.

------
larrykubin
My reasons for using Python frameworks (Django or Flask) are pretty simple:

1) I find Python code easier to read and 2) Rails seems to evolve a bit too
fast for me. I find it easier to keep up with Python frameworks.

------
jarrett
Let's look at some metrics of maturity and community size.

Django and Rails are almost the same age. Rails is only a year older, which
doesn't mean much after so many years have passed.

The numbers of Google search results for "Python Django" and "Ruby Rails" are
on the same order of magnitude, with Rails having around 50% more. Likewise
for "Rails site:github.com" and "Django site:github.com"

The differential is bigger on Stack Overflow, with Rails having about twice as
many tagged questions. They're still on the same order of magnitude.

One could of course do a feature-by-feature comparison, but I don't find those
particularly useful when looking at frameworks. That's because a framework is
a long-term investment. You're not just buying into the current or upcoming
version, but all future versions. (Unless you make the expensive choice to
switch.) If one has a feature that turns out to be really useful, there's a
very good chance the other will acquire that same feature soon enough.
Especially considering the size of the Django and Rails communities.

Will Django 1.5 or Rails 4 will change the balance significantly? My guess is
not. It's like an arms race: One side or the other may claim the advantage
from time to time, but with plenty of smart people working on both, cross-
pollination should ensure that they stay fairly comparable.

All that being said, I prefer Rails (largely due to Ruby) and am quite happy
with it. Though if I were doing scientific computing, I'd take into account
what bayesianhorse said.

It's also worth considering that the whole paradigm underlying Django and
Rails, wherein you render a bunch of HTML with your choice of backend
language, may not last forever. With the client side getting heavier over
time, the advantages of sharing code across client and server may push the
mainstream away from Ruby and Python. Or not. This isn't a prediction; more
like a "what if."

~~~
legutierr
> It's also worth considering that the whole paradigm underlying Django and
> Rails, wherein you render a bunch of HTML with your choice of backend
> language, may not last forever. With the client side getting heavier over
> time, the advantages of sharing code across client and server may push the
> mainstream away from Ruby and Python. Or not. This isn't a prediction; more
> like a "what if."

From that perspective, one thing that Django has going for it is the Django
REST Framework (<http://django-rest-framework.org/>), which is pretty great.
Of course, it's probably the case that Ruby has something similar.

~~~
jarrett
Yep! Rails has a lightweight, API-oriented flavor.

But even without the HTML templates--even if you're just serving up JSON or
XML or whatever--you're still stuck with one language on the client and
another on the server. What I'm really curious about is whether the advantages
of having a single language on both client and server will ultimately outweigh
all other concerns for most web projects. I have no idea what the answer to
that question is.

------
kennu
Rails currently wins if you want to make a "typical" web application, which
allows people to sign up with email/password/Facebook. Implementing these
things with Django requires uncomfortable tweaking, because custom user models
have not been available until Django 1.5 (still unreleased).

It is also very painful to make asset pipelines work in Django (SCSS &
CoffeeScript compilation and minification). There are various solutions which
require various amounts of tweaking, and which can break in unexpected ways on
SCSS syntax errors etc. In Rails, all this just works out-of-the-box.

And lastly, Django's app ecosystem is very tied into the Django ORM data
model, which is currently very tied into MySQL/Postgres. If you want to use
MongoDB (with MongoEngine), most existing Django apps won't work with it. On
the Rails side, Mongoid is an established ODM, and there are existing gems to
make most things work with MongoDB without any tweaking. This means you will
have the email/password/Facebook authentication (Devise/Omniauth), RailsAdmin,
CanCan permissions etc. working right away, and your whole web app can run on
MongoDB if you want.

So, even though I'm a long-time Django user and fan, I think it just hasn't
kept up with the times. Nowadays Rails works better and is more productive for
typical new web projects. (But realtime/single-page-apps are a different
story, there I lean towards Derby&Meteor.)

------
danso
A related question: what is the state of Python's lighter frameworks versus
Ruby's Sinatra? I haven't used Rails in awhile, but since ActiveRecord,
ActiveSupport, etc have been refactored into framework agnostic libraries,
I've been able to build lighter websites using Sinatra or Padrino (which sits
atop Sinatra) using my Rails experience. And of course,Rails itself has
allowed for components to be switched in for their AR equivalents, e.g.
MongoMapper

How swappable are the core components of Django?

~~~
civilian
You can swap out Django's built-in ORM for something else (like SQLalchemy)
and you can also swap out the django templating for something else if you
want.

Flask <http://flask.pocoo.org/> is pretty awesome and I've used it for a
project that was really light on server-side code (<http://palettecomp.com/>),
but I've never used Sinatra so I don't know how it compares.

~~~
r4vik
Flask is basically exactly the same as Sinatra

------
hcarvalhoalves
These frameworks have use cases different enough for this comparison to not
make sense.

Although you can build a product using any, Django is out-of-the-box more
useful for building publishing platforms or content-heavy sites, while Rails
is more about scaffolding and REST APIs.

There are also the obvious differences between the language stacks, libraries
available, etc. This may be more important than frameworks themselves, which
are mostly glue logic.

------
obviouslygreen
I think the whole "x vs y" idea of Django and Rails is unnecessary. They serve
similar purposes but they do it in different ways (the most notable of which,
obviously, is the language they use), but comparing them is a questionable
pursuit.

If you already have a preference between Python and Ruby, for whatever reason,
then your choice is probably already made. If you don't, more important than
attempting to build something in both -- which won't really help unless it's
something real-world and in-depth, which is unrealistic -- might be to
consider the languages themselves and decide which better suits the way you
think/code.

Of course, if you have a specific project or set of projects you're looking to
build, reviewing the available libraries for the languages and frameworks as
well as their maturity and prevalence would be important.

If you're wondering which suits _you_ better as a long-term time investment,
reviewing the community and the doc/misc websites surrounding both frameworks
would be a good idea. People are pretty opinionated about those particular
communities; trying to decide which you find more helpful or have an easier
time gleaning information from and/or interacting with could prove valuable in
terms of deciding which language/framework would work best for you.

I guess this is a long-winded way of suggesting this is the wrong question; it
just isn't meaningful. You could attempt to compare them on all sorts of
metrics, but despite their similarity of purpose, I think you're likely to
find your own subjective review vastly more useful than anything else.

[edit: This is also intended as a mild indictment of the question, as
specifically disqualifying other mature web language/framework combinations
does everyone a disservice, though to include them all would make the question
even less meaningful.]

------
eedeep
You might find this post from Stephen MacDonald useful if you're thinking
about taking the Two Week Challenge (or the One Week Challenge if you're
already familiar with one and want to try the other):
[http://blog.jupo.org/2011/07/30/rails-quick-start-for-
django...](http://blog.jupo.org/2011/07/30/rails-quick-start-for-djangonauts/)

------
nobleach
One thing that rarely gets brought up is deployment. If you're in a shop with
Windows webservers. Django pretty much isn't going to happen for you. I
remember a couple of years ago there was some effort toward a WSGI module for
Apache based on Cygwin or something.

I'm a huge advocate of JRuby. It's Ruby for the JVM. Consider the fun of
getting to write Ruby, and the joy of knowing you can deploy to anywhere with
a JVM. I'm not a Windows fan by ANY stretch. I do all my development on my
Linux laptop... but the powers that sign the checks think Windows is swell. So
consider where you'll be deploying.

------
icn2
I have more experiences on django. Recently I looked into ruby on rails and I
don't want to look back. * bundle install. In ruby everything is a gem when
you deploy to a new machine all you need to do is "bundle install". In django
I really don't see a comparable facility. I recall I forgot something until I
got an "import module error" * scaffold. ruby on rails scaffold just makes
development usper fast. * dev/test/production config. Well it is just very
convenient. * db migration. migration make db update/change much easier.
Changing db/data schema is so painful in django.

~~~
beatpanda
There's a comparable facility that's part of Django best practices, but it's
not bundled with Django. It's a pip requirements.txt file.

Substitute 'bundle install' for 'pip install -r requirements.txt' and it's
basically the same thing.

~~~
aGHz
It bears mentioning that this is usually done in conjunction with virtualenv.
The common practice is to include a requirements file in your repository, and
have every repo clone live in its own virtualenv. This is something I very
much love in the Python world: encapsulation of deployments is separate from
package management.

------
iends
I'm a python/django developer. If I could do it over again (ignoring the fact
I've basically switched to an all javascript stack outside of work), I would
go with rails/ruby.

I think there are more rails jobs than django jobs, at least the type of job I
want, and especially in my geographic area (North Carolina).

I feel like the ruby community is much larger, much vocal, and many of the
startups I actually buy stuff from use ruby.

I imagine the tooling is pretty compatible, but I'm not that familiar with the
ruby world. At the startup I used to work for we deployed django on heroku
much like one would do in the ruby world.

------
kyllo
Is Django 1.5 finally going to support Python 3? Python 3's been out for what,
5 years now, and the major web framework for the language still doesn't
support it yet?

The whole Python 2 / Python 3 incompatibility issue was one of several reasons
why I decided to focus on learning Ruby and Rails instead.

~~~
FireBeyond
"The whole Python 2 / Python 3 incompatibility issue was one of several
reasons why I decided to focus on learning Ruby and Rails instead."

Confused. It seems, and I'm happy to be corrected, that many new Rails
versions deprecate, often with little notice, even core components. Or am I
wrong?

~~~
Buzaga
Yes this happens. But the point is that Rails and its community like to stay
on the edge, if something deprecates you fix and it's done... the thought of
framework developers trying too hard to be compatible with everyone's apps,
people backporting language features to an older version so they don't have to
switch and a popular framework dragging the evolution of a language is much
more worrisome to a lot of developers

I'm not entitled to talk about Django but that's my perception...

There was a really funny comment in a thread like this back then that
impersonated Rails saying "New Ruby version? let's deprecate everything!"

and Django going "On the weekend we're gonna discuss making Django compatible
with the 5 year old Python"

And then someone said "What I like about this comment is that it pisses off
both sides of the table"

:p

------
jayferd
It's more like Python toolchain vs. Ruby toolchain these days.

------
marcrosoft
I like them both but I have to say Django updates have been easier to deploy
than Rails updates. Something always seems to break when I upgrade Rails.

------
lukasko
Compared to Django I find the Ruby tool chain to be much more polished.
Getting things working on Django requires a lot of tweaking and tinkering.

------
smonff
Please check this WikiVS page www.wikivs.com/wiki/Python_vs_Ruby.

------
mkadlec
Is Django/Python going to get rid of the double underscore convention? If so,
I'll switch from Ruby/Rails... :)

~~~
lclarkmichalek
It's not a convention, it's part of the language.

~~~
mkadlec
I know, that the worst part! I like Python, in fact the indentation convention
makes it really nice to read, but why did they uglify it with the double
underscores?

------
sergiotapia
COMPLETELY 100% unscientific, but in my glances and reading of the Django docs
I found that they make heavy usage of symbols such as [, ] in code.

I like Ruby's terseness. Fewer keystrokes is a win for me, especially when you
have a shit keyboard (pardon my french).

Django feels very CakePHP-y, if that makes any sense?

QUICK DUMB EXAMPLE:

Django:

    
    
        from django.db import models
    
        class Person(models.Model):
          first_name = models.CharField(max_length=30)
          last_name = models.CharField(max_length=30)
    

Rails:

    
    
        class Person < ActiveRecord::Base
          attr_accessible :first_name, :last_name
          validates :first_name, :length => { :maximum => 30 }
          validates :last_name, :length => { :maximum => 30 }
        end
    

\---

Which is simpler to type, ergonomically speaking?

~~~
aGHz
You are probably trolling, but just the same, I don't like it when people get
downvoted without explanation. Ergonomically speaking, count the number of
characters that need to be input by holding the shift key, and that will tell
you which is simpler to type.

edit: Well when I started replying, you were well into the light grey and with
no reply.

~~~
sergiotapia
Just because you do not agree does not mean I'm trolling. Don't do that here
on HN.

~~~
aGHz
I didn't mean it as an insult. But when you make a statement then provide an
example that contradicts it, that's usually a troll move. Ergonomically
speaking, the example you provided is easier to type for Django than Rails.
Again, didn't mean to offend.

