Earlier quoted context omitted.
This is rediculous. Everyone's app is different, and so Django is rightly agnostic as to how your settings are stored, and which are loaded. As for the scope of the problem: dealing with multiple development settings is Section 1, Page 1 of professional programming. It's a solved and trivial problem. This isn't like coding your own ORM or templating language.
Okay, let me rephrase. It's not trivial. In rails, it's trivial. The framework has knowledge of these separate states of applications. Deploying a serious, hardened service on top of Django is an order of magnitude more complicated than something like Rails. Schema migrations are yes, a "solved" problem, if by "solved" you mean a third party application that isn't baked into the framework. Having built a service that…
> Deploying a serious, hardened service on top of Django is an order of magnitude more complicated than something like Rails.
That's funny. How so? I just start gunicorn, point nginx at it, and I'm ready to go. Of course, you could just as easily do it 500 other ways that might make sense to you more.
> Schema migrations are yes, a "solved" problem, if by "solved" you mean a third party application that isn't baked into the framework.
This is absolutely the most absurd thing you've said so far. South handles migrations very well, the code of of excellent quality, and I'm always thrilled to see incremental improvements come down the pipe when they're ready. I don't have to wait for a new Django release.
> Having built a service that hosts Django apps, I can tell you that serious, hardened, services are not as trivial as you think to build with Django. There are countless headaches, and at this point it makes sense to use Rails over Django if you care about making your life easy.
Completely unsupported drivel. We run two separate PCI compliant websites with well over 10k uniques a day per, and have had a pretty easy time of securing both. Django bakes in XSS and a lot of other protection with little to no effort. SQL injection attacks become all but impossible if you don't do anything goofy.
> I'm not saying Django isn't without its advantages, but those advantages tend to pale in comparison to some of the problems when you scale past 10 users of a trivial app like a blog.
Work we do for client spans in the many thousands of users. Django bears the load well, has kept ourselves and our clients safe for over four years now, and lets us develop and deliver quickly.
I'm sure you can do the same for RoR, but why dump on Django when you clearly don't have a firm grasp on it and/or Python?