Need a compelling argument to use Django instead of Rails

[Alex Martelli]

Ray <ray_usenet at yahoo.com> wrote:

> Damjan wrote:
> > BTW I'd choose TurboGears for it's flexibility, but I guess Django could be
> > nice when more rapid results are needed (and the problem doesn't fall too
> > far from the Django sweet spot).
> 
> Well actually I was thinking of exaclty the same thing, because our
> apps are mostly CRUD apps anyway. However I just learned of one very
> big killer--lack of support for Oracle and MS SQL Server. That pretty
> much shoots Django down from the list, and with it Python.

According to
<http://wiki.rubyonrails.com/rails/pages/Framework+Performance>, with
Rails...:

"""
When connecting rails to Oracle the performance dropped to the extent it
made any production use of the product useless.
   ...
Oracle. I would bet performance degrades dramatically when Rails
connects to Oracle as Rails does not use Bind Variables or cache
prepared statements. Not using bind variables in Oracle is the single
most common mistake. When running the load test connected to Oracle,
does Oracle consume a lot of the CPU?
Its unfortunate, as until Rails handles Oracle correctly, its not really
fit to be used on it, and I was really hoping to use it there!
"""

IOW, if these comments are correct, Rails is also _practically_ unusable
with Oracle.  Meanwhile, Django has experimental Oracle support with a
patch (<http://code.djangoproject.com/ticket/1990>, latest checkin is
from Jul 31, but it has been around for over a year in some form or
other).  As to what will mature first, Rails/Oracle performance or the
Django/Oracle patch, who knows.  I suspect it won't matter much, because
"buzz" trumps substance (in the short run, at least), and Ruby on Rails
has buzz (according to Tim O'Reilly's reports at OSCON last week, sales
of Ruby books have overtaken sales of Perl books recently -- Python
books, while gaining relative to Perl, are still below).

The one big issue that may preserve Perl, Python and PHP against Ruby's
onslaught is -- acronyms.  Any of the "P" languages can acronymically be
part of a "LAMP" setup, one of the coolest acronyms in years; indeed,
BSD, PostgreSQL and lighttpd may already have been handicapped by the
un-coolness of acronyms such as BLPP.  But Ruby suffers even worse here,
since somebody using Ruby instead of a P-language would be a... LAMR!!!

If I were on the board of the Ruby equivalent of the PSF, I'd be
lobbying hard for the language's name to be changed to PRuby -- with the
P being mute, as in Wodehouse's character Psmith.  _That_ would remove
the acronymical barrier and ensure PRuby's triumph.


Alex