Yes, the number of choices in Rails has proliferated, but a new user can easily ignore these choices. I don't think the situation is at all equivalent to the Java stack (which is the only other one I can comment on).
To use Java, you probably want to use Maven, Spring for dependency injection, an MVC framework (Struts 2, Spring, Tapestry, etc...), an ORM framework (probably Hibernate, probably with JPA?), though there are other choices.
This blog lists a bunch or Rails/Ruby choices. However, it's important to keep in mind that essentially all of the things a newbie needs to get started with Rails are in a single, self contained framework that is (in my opinion) incredibly easy to use.
I had well over five years of Java experience when I took on the latest in Java-based web framework. A book on Struts 2 covered Spring, but not Maven. A book on Maven covered MVC, but used Spring's MVC. A book on Spring MVC used Ant for the build, not Maven. Ultimately, I had to spend a great deal of time researching these technologies to just get my first simple app up and running. You should spend some time getting to know your framework and not just rely on magic. But should you have to do this for weeks or even months before you can write a simple webapp?
For rails... well, there's absolutely no need to worry about JRuby, IronRuby, or Ruby Enterprise, and whatever tutorial you're doing on Rails will tell you what version of Ruby you need. You don't need to download any of that windows crap mentioned here. You can ignore Sinatra for the time being. Gems are utterly simple to use (try adding a Maven dependency some time, especially one that doesn't have a public repo). You don't have to download any database to get started with rails, but you will have to spend a lot of time figuring out how to configure applicationContext.xml in Spring (or however you decided to go about it).
In fact, I think you can be a successful web apps developer with Rails and never bother with anything other than the basic defaults (ok, you'll want to use a different database).
Ok, I realize I've been ranting. But there's a huge difference between a proliferation of choices that can be ignored, and a proliferation of choices that have to be understood and dealt with before you can write your first app.
It's easy to paint everyone's experience with your own isn't it?
I answer questions from people new to Ruby a lot (given that I wrote one of the few and the earliest introductory books for Ruby that's free) and they are VERY often the exact questions he mentions here. Maybe people are too lazy to find the answers. Maybe they're utterly immobilized by a new tech stack that has a lot of choices. Maybe they just aren't as smart as you are. Whatever it is, we really need to find a simple way to address these questions. I think a lot of them are already addresses through blog posts, and as you mentioned, through the tutorial you're following, but a lot of them aren't (and sometimes they're answered incorrectly due to the age of the content or simple ignorance on the author's part).
Let's not pretend these people don't exist just because you aren't one of them. Many people do have to deal with this stuff up front due to the nature of the work they plan to do with it, and if the information isn't accessible, they'll just move on to somewhere it is.
"Let's not pretend these people don't exist just because you aren't one of them."
I assure you that I am one of them. I'm probably one of the people whose questions you helped answer on a discussion forum.
The part where I am, as you said, painting everyone's experience with my own is comparing Rails to a Java based web programming stack. Someone coming from PHP, for instance, might find it kind of difficult to use a framework that (essentially) can't be used without some knowledge of OOP, MVC, and so forth (as opposed to just putting some things up on a page). Sure, there's a learning curve.
But the "immobilization" you mentioned happens in degrees. Yes, it always takes some work to get up in running, because programming isn't easy. However, I don't think that the range of choices immobilizes a new programmer in Rails to anywhere near the degree that it does in the Java world.
So while I would agree that I have a particular angle that isn't necessarily shared by everyone struggling with rails, I don't think that my experiences are unusual for a programmer with experience in Java who has gone through the learning curve on web app development in Java and Rails.
"Whatever it is, we really need to find a simple way to address these questions ... they'll just move on to somewhere it is."
Really? Java is worse in this regard! C# even worse since you have to use mono if you aren't on windows and mono isn't 100% up to date with C# from MS. Python is very similar to ruby on this front, lot's of choices. PHP is well PHP.
I still think ruby in the best in this regard. install 1.8.7, gem install rails, but the agile rails book, start coding. A lot of the stuff in this article is just noise that no one needs to think about. In fact, there is a giant 'getting started' link on the rails site which answers this question pretty well.
A lot of it is noise, absolutely. But while I wrote this as satire, it's based on the experiences I've seen from new developers. If you didn't know any better, it could be easy to think that Rails devs all use Rails 3, are completely swept up in the NoSQL movement, and don't have libraries that will run on Ruby 1.8
Really this article was designed to point out that an overabundance of choice - even though they're great choices - can be harmful to new developers. And people should consider joining things like RailsMentors.org right now. Because more than ever, this is a time where one-on-one mentoring is all but necessary.
As far as greener pastures...I'd hate to see the day when any community measures itself by comparison to other communities, rather than on its own accomplishments.
Yes, the number of choices in Rails has proliferated, but a new user can easily ignore these choices. I don't think the situation is at all equivalent to the Java stack (which is the only other one I can comment on).
To use Java, you probably want to use Maven, Spring for dependency injection, an MVC framework (Struts 2, Spring, Tapestry, etc...), an ORM framework (probably Hibernate, probably with JPA?), though there are other choices.
This blog lists a bunch or Rails/Ruby choices. However, it's important to keep in mind that essentially all of the things a newbie needs to get started with Rails are in a single, self contained framework that is (in my opinion) incredibly easy to use.
I had well over five years of Java experience when I took on the latest in Java-based web framework. A book on Struts 2 covered Spring, but not Maven. A book on Maven covered MVC, but used Spring's MVC. A book on Spring MVC used Ant for the build, not Maven. Ultimately, I had to spend a great deal of time researching these technologies to just get my first simple app up and running. You should spend some time getting to know your framework and not just rely on magic. But should you have to do this for weeks or even months before you can write a simple webapp?
For rails... well, there's absolutely no need to worry about JRuby, IronRuby, or Ruby Enterprise, and whatever tutorial you're doing on Rails will tell you what version of Ruby you need. You don't need to download any of that windows crap mentioned here. You can ignore Sinatra for the time being. Gems are utterly simple to use (try adding a Maven dependency some time, especially one that doesn't have a public repo). You don't have to download any database to get started with rails, but you will have to spend a lot of time figuring out how to configure applicationContext.xml in Spring (or however you decided to go about it).
In fact, I think you can be a successful web apps developer with Rails and never bother with anything other than the basic defaults (ok, you'll want to use a different database).
Ok, I realize I've been ranting. But there's a huge difference between a proliferation of choices that can be ignored, and a proliferation of choices that have to be understood and dealt with before you can write your first app.