Rails 3: Django with a funny syntax

Posted by Elf Sternberg as python, ruby

From the announcements for Rails 3:

The upcoming version 3 of Ruby on Rails will feature a sexy new querying API from ActiveRecord. Here is an example:

User.order('users.id DESC').limit(20).includes(:items)

In other words, Rails is now Django.


  • Each application now has it’s own name space, application is started with YourAppName.boot for example, makes interacting with other applications a lot easier.
  • Rails 3.0 now provides a Rails.config object, which provides a central repository of all sorts of Rails wide configuration options.

In other words, Rails is now Django.

To be fair, these are huge improvements to Rails. They’ve needed to do these things for a long, long time. The separation of application namespaces is especially powerful– it’s what gives Django a massive chunk of it’s dynamism. It’s good to see that these great ideas, which have been in Django since version 2, have now made it into Rails, just as the Django people start grappling with their own version of Capistrano (Fabric) and their own deployment issues. Rails’ migration path has always been obvious, a pythonic value, while Django has two migration tools (South and Evolution), which is more a rubyish value, and the Django team has decided to leave migration tracks up to outside development teams may-the-best-solution-win.

So, we’ll see. I’m installing Rails 3 this morning, and who knows?  Maybe it’ll seduce me back to working with Rails again.

2 Responses to Rails 3: Django with a funny syntax


August 18th, 2010 at 8:28 pm

So? Back using Rails?


August 26th, 2010 at 8:55 am

Cross-pollination is good! Despite the many criticisms that Django has received for doing things their own way, it was the right decision. It is likely that had Django adopted some other ORM instead of their own, these elegant ideas would never have filtered into Rails.

However, to say that Django has two migration tools isn’t really true. I realize that Evolution is still under active development, but it is still less stable than South and has comparatively few users.

South is now the defacto standard. There were even discussions between the Django and South teams about turning South into a contrib. The only reason they didn’t was so that South would not be tied to the Django release cycle.

Comment Form

Subscribe to Feed



February 2010
« Jan   Mar »