I went with Django because I could read its codebase, but found the Rails codebase too cryptic. Rails magic, epitomized by the pluralization rules, was also a turnoff - the prospect of debugging in that world seemed scary.
The case for Django is the clean, modular architecture, making it possible to split a project into reusable applications. With Rails DHH took a strong anti-component stance, deciding that it was better to make everything easy to reimplement. As a result, even common things like the registration gem have too many integration points. This decision will matter in the long run.
Django has access to all the mature Python libraries, but its ORM is limited. Pythonic model specification and automatic model validation against the SQL metadata is great for the DRY philosophy; but there is no migration metaphor (yet), there's no table inheritance metaphor (yet), and even pessimistic locking requires a hack (so far). The best hope is an effort under way to make the Django ORM a wrapper for the infinitely more powerful SqlAlchemy, which some people use on top of Django anyway, foregoing its data-related tools including Admin.
And of course Rails is integrated with every concievable Ajax technology, allowing a hundred ways to implement the <blink> tag.
The Rails community is growing from an influx of ex-PHP scripters, bringing with them less disciplined coding styles, which the more Perl-like overly-concise features of Ruby encourage. The RoR environment is going to be the new Perl - a powerful tool for certain applications, applied far more broadly than intended, with a CPAN full of one-off solutions for every concievable problem, but no culture of solidly engineered modules.
The case for Django is the clean, modular architecture, making it possible to split a project into reusable applications. With Rails DHH took a strong anti-component stance, deciding that it was better to make everything easy to reimplement. As a result, even common things like the registration gem have too many integration points. This decision will matter in the long run.
Django has access to all the mature Python libraries, but its ORM is limited. Pythonic model specification and automatic model validation against the SQL metadata is great for the DRY philosophy; but there is no migration metaphor (yet), there's no table inheritance metaphor (yet), and even pessimistic locking requires a hack (so far). The best hope is an effort under way to make the Django ORM a wrapper for the infinitely more powerful SqlAlchemy, which some people use on top of Django anyway, foregoing its data-related tools including Admin.
And of course Rails is integrated with every concievable Ajax technology, allowing a hundred ways to implement the <blink> tag.
The Rails community is growing from an influx of ex-PHP scripters, bringing with them less disciplined coding styles, which the more Perl-like overly-concise features of Ruby encourage. The RoR environment is going to be the new Perl - a powerful tool for certain applications, applied far more broadly than intended, with a CPAN full of one-off solutions for every concievable problem, but no culture of solidly engineered modules.