Ask HN: State of Django vs. Rails? | Hacker News Reader

Ask HN: State of Django vs. Rails?

55 pointsargonaut78 comments

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.

Some factors to consider beyond just the design of the frameworks: productivity, readability, documentation, activity of community, tooling, ease-of-use/learning, etc.

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.

View on HN

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.

> 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.

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.

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".

After learning a couple of (different) languages, learning the new one is easy. So easy that it usually equates learning its standard library. So learning either Django or Rails, if you are moderately experienced developer shouldn't really take more than a few weeks.

Of course, learning the first language is challenging.

I have become proficient in about 10-15 languages over the years, but Python is sufficiently different from all of them that 2 weeks is not enough to give Django a fair trial. I'm sure Rails is the same. Knowing 80x86 assembler, Commodore 64 basic and Amos only go so far, but maybe knowing Python it is easier to switch to Ruby.

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/

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.

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.

It is good advice; it just isn't time-effective to do a thorough job. By the time you've gotten through the tutorials and maybe built a couple simple sites, you've probably gotten to the beginning of understanding how it works, but you have yet to do basically anything that would be considered working with the framework as it applies to what you'd actually do on a real project. You might understand the very basics, but extrapolating that into "this is how working with it actually is" carries the very real possibility of a rude awakening.

How thorough does an evaluation need to be? I'd suggest that doing a few things less-thorough than a real project is sufficient to get a feeling for the framework. There are real projects done in both frameworks, there isn't going to be a point where you find some pitfall and go, "welp, looks like we have to start over in Rails" or whatever.

This is possible, for certain definitions of "site".

It's not a question about web frameworks. It's a question about languages.

I you like Python and it's Zen, use Django. Otherwise, use RoR.

If he can't decide, he can still use Perl Catalyst or Mojolicious ! Catalyst guy have a good way to define what's'the difference between RoR and Catalyst: RoR makes easy things simple but complex tasks very hard (when try to run out of the rails). Catalyst (and I believe Django too) makes easy things a little more difficult but complex things possible and maintainable.

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.

> 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'?

> LESS has fallen out of favor

Eh, I don't know, Twitter bootstrap users don't appear to agree. I know it's fallen out of favor for DHH, but I don't know if that's generally true.

> 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'?

No idea, because I've never tried to do it, but the one I was referring to seems to make it pretty easy: http://sunlightfoundation.com/blog/2011/01/20/django-mediasy...

> Eh, I don't know, Twitter bootstrap users don't appear to agree.. I know it's fallen out of favor for DHH

Yeah, that's all I mean. I agree that it hasn't necessarily gone away in the larger sphere. Just that the Rails community has moved to a different default, so LESS gets harder to use.

I personally am glad, though. I find SCSS more powerful. See, for example, the if statements and loops it gives you:

http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#co...

For another example, around the time when Rails made the switch, I started running into serious problems using media queries with LESS, whereas they've always worked great for me in SCSS.

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.

> 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.

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)

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

This has been fixed in the upcoming Django 1.5. I don't want to argue with you, just point out this tiny detail.

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?

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.

> 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.

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

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

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

That's a very compelling reason to use Python if you need those things.

On the flip side, RubyGems is much bigger than PyPI and has a lot of modules that you won't necessarily find equal counterparts to in PyPI.

I think there's a lot of use cases one can come up with where one language's library offerings suit them better. That was how I chose between Ruby and Python. I chose Ruby+Rails but it very, very easily could have been Python+Django.

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.

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/).

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

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)

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.

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.

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."

You left out the differential in the availability of books. In my experience, Rails has a larger online community, but Python has more printed books.

I think this is a product of the speed at which Rails develops - it is more likely that a Rails book will be outdated by the time it is finished than a Django book.

Also jobs. The following are searches for "Ruby on Rails" and "Django" in New York, NY

  Ruby:
    - indeed.com - 507
    - monster.com - 66
    - dice.com - 96
  
  Django:
    - indeed.com - 242
    - monster.com - 30
    - dice.com - 65

Edit: formatting

Edit 2: Though you could argue that Ruby is mostly used as Ruby on Rails, while you could search for "Python" jobs if you have experience with Django.

Edit 3: what is with the downvotes? If you want to learn a new framework whether you can get employment is something to consider.

> what is with the downvotes? If you want to learn a new framework whether you can get employment is something to consider.

Consider maybe, but becoming an X developer is usually not a great idea, for just about any value of X. So, if you want to do Webdev, why not be proficient in both to maximize your chances?

Well, true, but we all must prioritize. Working time is limited. "Be proficient in both" is not necessarily practical for everyone. It may not be for the OP.

Also, it's conceivable that if you split your time amongst different frameworks, you could be at a competitive disadvantage against someone who's more specialized. (Of course, the complete opposite is also conceivable, so don't take this as me advising people to study just one framework.)

I remember a few years ago looking at the same stats and seeing Rails be an order of magnitude larger. They seem to have equalized quite a bit since. From the point of view of becoming a great web app dev, yes learning as much as you can is great. From the point of view of investing in yourself given a limited amount of time, that may not be true. For example if you have 6 months where you can switch careers, learning Haskell might not be your best choice. OTOH PHP seems great, since it is used in plenty of places.

These numbers do not mean that if you know X you will get a job. They simply tell show that there is some level of usage of these technologies in the industry. Try doing the same search for Scheme or Haskell or even Erlang. All great to learn and will make you a better professional, just not greatly popular in the wild.

From that point of view Java or PHP webdev is a better choice, because there is vastly more openings. Learning Rails and/or Django is a more of luxury if you just go to get a job.

> 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.

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.

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.)

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?

Python's Flask is a superb Sinatra clone, and Django's ActiveRecord equivalents are equally useful in Flask, especially for Mongo. Flask sits on top of Werkzeug, which is similar in power and use cases as Rack - middleware, fine-grain auth, etc.

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.

Flask is basically exactly the same as Sinatra

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.

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.]

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...

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.

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.

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.

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.

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.

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.

Yes, but the app ecosystem not so much.

Yes, Django 1.5 supports Python 3 although the authors recommend waiting until 1.6 for production sites (https://www.djangoproject.com/weblog/2012/aug/19/experimenta...). The larger question is whether the libraries you want to use support Python 3. Common libraries such as django-debug-toolbar unfortunately do not yet support 3 (https://python3wos.appspot.com/).

To be fair, very few projects from the Python ecosystem have been eager to jump to Python 3.

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

Although I understand that mentality and share it on some level, that was a bad way to make that decision. If you write Python 2.7 and avoid things marked deprecated, you are nearly compatible with Python 3 by default.

Besides, this one isn't Django's fault.

"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?

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"

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

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.

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.

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

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

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

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?

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?

I don't agree with your point or its opposite, but the example you give seems like it is at odds with your observations on brevity and symbol usage.

with Ruby 1.9 you don't need the '=>' for hash values:

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

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.

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

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.

"Fewer keystrokes"

Your example, Ruby has 26% more characters (194 vs 154).

"I found that they make heavy usage of symbols such as [, ] in code."

Your example, 3 sets of parentheses, 4 equal signs, 4 underscores, one colon in Python.

In Rails, 2 sets of braces, 4 assignment operators (=>), 10 colons, 4 underscores and a <.

I guess I'm not seeing either the brevity or heavier use of symbols in your example...

This is kinda funny, because your example is full of : which is even more annoying to type than ,

If you have a shit keyboard, treat yourself to a nice one, I bought a mechanical one for 50€ and it is pretty damn good and I plan to keep it forever.

Reply on news.ycombinator.com