With Merb, I am afraid this issue will be even more pronounced. Merb isn't as widespread, and seems to be technically solid. This, I suspect, will only give these Ruby assholes more reasons to bring all that elitist crap to the party.
To me this just sounds like Common Lisp vs Scheme all over again.
Not likely. Merb will accumulate plugins. Rails had most of its complexity, or at least signs of it, from the beginning.
One thing that has stung me about Rails is the conceit; if you have a requirement that runs against the grain, Rails developers seem to have no problem in saying "that's stupid; you shouldn't want that."
So again, in this article, I was not trying to convince people to give up on what they use, but instead offering an alternative for people who are looking for something else.
As Matz said: "We have several post-Rails frameworks, which is very good, and I believe in diversity."
1. The default full stack will be a lot less thoroughly documented, tested and debugged because a lot fewer people are using it.
2. The chances that I can just jump in and start hacking productively on somebody else's Merb app are slim because it's likely I'm not familiar with some of the components you're using.
I still don't understand at all why I'd want to use Merb. What problem are you trying to solve here? Being slightly better than Rails in a few respects isn't even close to good enough to compensate for the lack of documentation, code maturity, available programming expertise, public success stories etc that Rails has going for it.
It doesn't help that today, adding more RAM costs very little, and that the new VM in Ruby 1.9 runs my Rails apps 3x to 5x faster, so I have very little reason to look outside Rails.
Perhaps because the pieces are sort of like Legos; they're designed to be mixed and matched with known results.
I prefer Ramaze, because it's more like Play-doh to Merb's Legos (sort of; I realize that's an over-generalization), but Merb is not some random collection of libraries. It is (I think) more like Rails with deliberate decoupling of components.
If you code Rails, try getting your 1 year old code run today. 99% chance is it will be broken by default. The goal on Merb is to maintain a stable, defined API so the code your write for it wont break down the line.
After coding Rails for 2 years, this is very appealing to me. There are lots of other benefits/drawbacks of Merb, but a stable API is what sold me on it.