This whole comment is rife with ignorance. > Deploying a serious, hardened service on top of Django is an order of magnitude more complicated than something li

This whole comment is rife with ignorance. > 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?