Here at Recrec Labs we have had a small tussle going almost since we started coding. Do we use Rails or Django? Our backend is in python, but our frontend is ruby – adding a layer of complexity to our architecture. There have been many discussions but generally “Switching isn’t worth it” wins out.

As a long-time PHP developer who started using Django almost 2 years ago, I have since then almost entirely dropped PHP  in favor of the Python/Django combination. I have always favored using Django’s more explicit format over Ruby’s implicitness. I believe if you want something to happen, you should say so.

In my (limited) experience with Ruby on Rails, I’ve generally been frustrated by the large amount of magic that I can’t opt out of. This is why I like the loose-coupling of Django. I have been able to use different parts of it in different applications: from URL resolvers for an IRC bot to templates for new machine deployment scripts. I’m likely biased, but that’s why I’m leaving the pro-Rails posts to the Rails-biased author.

However, ignoring the many programmatic differences between Python/Django and Ruby/Rails, there are some more pragmatic differences I’d like to point out. These are in terms of CPU and memory usage, two of the more expensive parts of a server. I’m fairly confident that any reasonable benchmark on the internet will show that a Django site uses far less resources than the equivalent in Rails. For one thing, since Rails isn’t loosely-coupled, if the Rails website doesn’t use every single feature of Rails, there is wasted memory because it’s all loaded into memory.

For Django, if you don’t use the database connectivity because you have a mostly-static website, and you only use the URL resolvers and template system, that’s all that gets loaded into memory and run through the CPU. Or if you want to run a script that iterates through the database and prune old data, you only load the database portion, and even then only the portion of that which pertains to your database (MySQL, Postgres, etc).

However, if you wanted to do any of these actions using Rails, a full system would be loaded each time. Now, if another Rails system is loaded, most of the memory will be shared, but I’ve seen private memory on these instances grow quickly.

On top of that, Ruby, itself, is slower than Python (though the latest Ruby implementations are closing that gap, but some of the benchmarks are rather dire.)

As the initial developer of the scalable interaction between Rails and our backend, I chose to use Django’s database connectivity over Rails’ ORM due to my greater familiarity with Python over Ruby, Django over Rails, and my continued yearning for Django. Thanks to Django’s loose-coupling and “inspectdb” management command, I got the official sanction to go ahead with this cross-framework connection that would have been too memory hungry in Rails.

So that’s the first part of our Django and Rails journey taken as a company from a generally pro-Django perspective. See you in the next step along the way as Rails is defended and lauded.

Be the first to comment

Leave a Reply

Your email address will not be published.