4 ms·

Much of what you say is opinion (so I can't disagree with it), but I think a couple of your facts are off vis-a-vis Django (or at least out of date): > Better

Much of what you say is opinion (so I can't disagree with it), but I think a couple of your facts are off vis-a-vis Django (or at least out of date): > Better release circle, as long as I know in Django didn't appear many features since 1.0 (mostly bug fixes and Python 2.x deprecation warnings) A lot has been added since 1.0, including multi-db support, admin actions, aggregates in the ORM (and other ORM improvements), class-based views, and many other features that I can't think of off the top of my head. One benefit of Django that you are leaving off your list is general stability, in the sense that the Django team is obsessed with ensuring backwards compatibility between major releases. My understanding is that the Rails team is willing to break backwards compatibility with a frequency that can impact people negatively. > Most Django libraries handling authentication stick on default User class, so it's difficult to subclass it if you require custom fields. This is changing in 1.5, the release of which is expected soon. > More libraries and more complex and configurable than django libraries. Honest question: how many of these Rails libraries implement things that are implemented in the Python standard library? In other words, are there more Rails libraries because Ruby itself is less complete than Python?

ersoft 14y ago
You're right, I can be out of date, I didn't code in Django in the past year, only in Ruby on Rails, but still I have the impression that things go much slower on Django release circle compared to Rails I'm glad to hear they are fixing the annoying bug in 1.5. About libraries, Python follows the idea that there should be only one way to do something, ruby follows the idea that there should be more ways to do something, this is why there are a lot of alternatives, for example: Testing: rails built in, rspec, minitest, test-unit, bacon, etc JSON Generation for views: jbuilder, rabl Memcache: memcached, dalli And many other gems have more than one alternative, which I think it's nice.
- dgunn 14y ago
  > About libraries, Python follows the idea that there should be only one way to do something, ruby follows the idea that there should be more ways to do something, this is why there are a lot of alternatives, for example:... I think you're stretching the meaning of this a bit beyond it's intent. It applies to more low level things than testing or JSON generation. The standard library does have a lot of excellent (and almost default) choices but it doesn't stop people from making alternatives.

ersoft 14y ago

You're right, I can be out of date, I didn't code in Django in the past year, only in Ruby on Rails, but still I have the impression that things go much slower on Django release circle compared to Rails I'm glad to hear they are fixing the annoying bug in 1.5. About libraries, Python follows the idea that there should be only one way to do something, ruby follows the idea that there should be more ways to do something, this is why there are a lot of alternatives, for example: Testing: rails built in, rspec, minitest, test-unit, bacon, etc JSON Generation for views: jbuilder, rabl Memcache: memcached, dalli And many other gems have more than one alternative, which I think it's nice.

dgunn 14y ago
> About libraries, Python follows the idea that there should be only one way to do something, ruby follows the idea that there should be more ways to do something, this is why there are a lot of alternatives, for example:... I think you're stretching the meaning of this a bit beyond it's intent. It applies to more low level things than testing or JSON generation. The standard library does have a lot of excellent (and almost default) choices but it doesn't stop people from making alternatives.