I just had a thought that's so obvious, in retrospect, I can't believe it took me three years to think of it.
And I just got time to reply to a three week old thread....
They pride themselves on how few features they have, because they've got the minimal set of features that make, say, to-do lists *possible*, instead of a complex set of features that make to-do lists maximally flexible.
I think this is true to a point, and for something like the apps it makes sense. I'm not sure it makes sense for Rails, though.
There are two kinds of complexity: avoidable and necessary. The former arises because the problem is overthought, you have more capabilities than you need, etc. The latter arises because the problem is actually complicated. The question I'm staring at is how to deal with necessary complexity.
If you imagine a platform as a set of minimum functionality plus support for the ways people want to extend it, you wind up with a natural tension in how to handle the support for anything beyond the core. On the one hand, you can build the functionality into the product, and on the other hand you can provide extension mechanisms. Rails has taken the latter path.
The problem with building everything into the core is you risk an overengineered pile of features that many people don't need. Exhibit HTTP request. Rails avoids this, but...
The problem with relying on extensions is you get a complex and subtly incompatible pile of reinvented wheels. Exhibit B: CPAN, complete with 5 hours research necessary to understand all 19 implementations of Hello::World. Rails' authentication seems to be reaching this point, complete with multiple auth plugins that repeat the same security holes*.
The community's common response to complaints about the latter is "YAGNI," but what people often mean is "I didn't need it, so you shouldn't either." This is a bit of a perversion of "YAGNI" as practiced in Agile methods, which could more accurately be described as "The customer doesn't need it until they tell you they do, in which case, they probably do."
You can probably trace this disconnect to the fact that the Rails core team is, on some level, the only customer of the product: they're the ones paying for development and the ones who determine the needs for the product.
To be clear, I'm not arguing that one approach or the other is right in the general case. I do think that knee jerk arguments (in either direction) aren't helpful. There are benefits and costs to each approach and it's probably worth understanding them in your situation**.
* FWIW, I'm anticipating a "Rails isn't secure" blog flamewar because authentication currently requires too much configuration and relies on too much generated code.
** Also,<http://www.jwz.org/doc/worse-is-better.html>
-faisal