I wonder what the motivation is. RoR is more mature and it otherwise is a fairly lateral port in terms of features and speed.
Both are dynamically typed and tremendously slow compared to the right .net or JVM stack. That would be my main criteria for stack selection in a project of this magnitude.
Marking a bug as "wontfix" because the developers of the RoR platform are arrogant enough to say, and I quote, "[...] figure out what other software is putting that version in your environment and stop it from doing so" is now called mature?
The dialogue on this bug alone was enough for me to put RoR in my rear-view mirror and not look back.
Which would you rather use: a tool which demands it is the only tool on your system which can set environment variables (RoR), or a tool which plays well with others (Django)?
"figure out what other software is putting that version in your environment and stop it from doing so"
I don't think you understand the context here. The Rails dev is saying (correctly) that nobody should be polluting the environment with a variable as vaguely named as "VERSION" this includes Rails.
Rails uses the "VERSION" environment variable temporarily for migrations. They're not trying to "claim" that variable name for themselves only.
As someone who's worked with both Rails and Django professionally for years, Rails is far more mature. Both are quality frameworks, but Django has far more warts, and the quality and number of good third-party libraries really isn't close. Django has forms and the admin going for it, and South is really excellent, but on the whole Rails feels better thought-out and more flexible than Django.
Django is very strong as a rapid-development tool (forms, generic views, admin), but I am more comfortable with Rails for a project with a reasonable timeline. Django class-based views are a far cry from Rails controllers.
They just need to rename the environment variable into something like RAILS_VERSION instead, as suggested by several commenters in that issue. Such a simple fix, I don't understand why they won't do that.
1) VERSION is a horrible name for a non-transient environment variable. It's fine if you're just using it on a per command basis (as rails does with 'rake db:migrate VERSION=123') but some app has stuck a ridiculously generic word into a global namespace.
2) (trivial) RAILS_VERSION would make no sense because it's the migration number you want to set your database too.
Any non-transient variable that you need to set should be specific enough to not conflict with other apps using the same namespace.
If anyone should go fixing things it's the fool who permanently stuck a variable called VERSION in their users global environment hash.
I agree that there is a problem and that it is affecting rails users. But, if for example some whacko was running around slapping all rails users with large fish would it be the rails dev teams responsibility to stop him? No.
No development team should have to tailor their app to compensate for the stupidity of one ignorant developer who couldn't think about the ecosystem that we all have to share. The only exception to this is when the idiot developer got a job building your OS...
Meh, using an environment variable named VERSION isn't too bright, and if it's for a single command then it should be a command line argument. RAILS_VERSION may not be appropriate but it's more intelligent than using an extremely generic and common name like VERSION.
Both are dynamically typed and tremendously slow compared to the right .net or JVM stack. That would be my main criteria for stack selection in a project of this magnitude.