I'm currently trying to decide what server-side language to learn and use for web development, and while it's relatively easy to get information on why x, y, or z is a good thing, it's harder to figure out the downsides to each of them.
In particular, I'm curious about what drawbacks there are to learning and/or using Ruby on Rails as opposed to any other given language/framework.
Speaking from experience: The downside is that you rely on the Rails framework a bit too much. This is a great and wonderful thing if you are only ever writing simple, greenfield CRUD apps that fall squarely into the Rails "sweet spot"; your productivity will skyrocket. However, the moment you have to do something outside that sweet spot - interact with an existing database, talk to another application that doesn't have a JSON or XML API defined, implement a complicated workflow, Rails will become your enemy. It is possible to do these things with Rails, but it goes "against the grain" so you're basically on your own with figuring out how to do it as the community will usually just respond with "Don't do that, it's not the Rails way" - this results in either lost productivity or very messy code as you basically have to hack around the Rails framework.
Also, there is the unspoken downside: Everything else will seem ugly and kludgy. Once you have tasted the sweet, sweet nectar of Rails (okay, evangelizing just a bit here...) everything else is swill. Going from Rails back to PHP, or ASP.NET WebForms, or Java is like walking on a bed of nails after frolicking in a lush garden; you won't see the other languages/frameworks in the same light, and while you may still appreciate them you will secretly long for Rails' loving embrace.
For your first server-side language, I feel like there can be a couple problems with RoR:
You're not just learning a language, you're learning a framework. I would definitely take some time to play around with plain old ruby before jumping into rails.
Since it is a framework, and an 'opinionated' one at that, I feel like it would give you a very limited scope of what all is going on in the framework.
Overall Ruby on Rails can be a good starting point to get the ball rolling, but there is a lot to learn about web development you may miss out on by being too reliant on a single framework.
I've tried to learn RoR several times and my biggest problem is always trying to get the packages to work correctly and the documentation. The problem with the documentation is that it always seems to be out of date (or very basic). I got the basics from the site but beyond that everything seemed so dated (even the book I bought and ended up returning). Another thing that could be a drawback is the dependencies that some of the libraries have and how they may conflict with another as stated by Ben Coe.
Something that I thought of later and instead of make it a comment, I'll just edit my answer is this: RoR has a chance of ruining Ruby for you. I know when I tried it, it made me think that "Ruby was stupid". Then a few months later I decided to give Ruby a go and loved the language, it was the framework that made me hate the language. I haven't dabbled in it much, but when I did, I really enjoyed Sinatra. I think I got the joy most people get out of RoR out of Sinatra.
If this is your first server-side language, it's as good as any. The thing to do is focus on one, and after you feel you've mastered it, explore others and deduce your own conclusions.
I work with RoR and ASP.NET on a daily basis, but strangely enough, I prefer the ASP.NET world, but that has more to do with personal philosophy than it has to do with the language or the architecture itself. (I'm a bit of a control freak and I personally gravitate to strongly typed languages).
Regardless, I say give it a go. RoR is a great environment to work in, but before you jump right into Rails, get comfortable with Ruby as a language. Beyond web stuff, Ruby is a pretty cool scripting language if you land up having to manage a *nix box and can save you a boatload of time.
As someone who learned Rails recently (as a hobby - never used it for commercial grade development) and had already worked in JEE and ASP.NET, Wayne M's answer rang very true.
Anyway, there is a subtle side to this which noone has mentioned yet, but which bothered me a bit with Rails - the strong reliance on convention over configuration.
Essentially, if you're used to "Find In Files"-driven orientation with a new code base, CoC is likely to annoy you when trying to pick up Rails. It's great for simple CRUD greenfields that are done precisely the Rails way (as Wayne M says), but for anything more unique and complicated, it'll be hard to work out what's going on if you try to work out the flow by searching for stuff in files to see how the plumbing is hooked up.
Though I think, this issue probably won't be as bad once you have a lot more experience with Rails. I can definitely see it being an issue for someone coming from oldskool Java/.NET web development who is used to a very verbose configuration flow - and is used to relying on seeing everything spelled out somewhere.
With me, the biggest problem with I learn my first X (in your case, X is a server-side web language/framework), it's that as soon as I see other problems, I immediately want to start applying X, even when it might not be the best option. I've gotten better at this, but it's still a strong tendency.
Ruby on Rails is a good choice to start with - there is a good community, plenty of documentation, and good tutorials. But be sure to keep the alternatives in mind, especially if you start doing more web development. RoR might be overkill for some problems, an inadequate solutions for others, and the best choice for a different set. Know it's strengths, weaknesses, and how to use the tool.
My advice would be to have a clear picture of the project that you want to complete and then just start trying to build it. As you run into problems you will eventually grab all the right tools. This approach is good because you are making decisions based off of succinct problems.
Another thing to do is buy books. Internet tutorials don't cut it in my experience; they also leave a lot of room open for distraction. When you have a book, the publishers have to make sure it provides value since they will lose money if it gets bad reviews. Spending a little money will save you a lot of time.
I honestly can't understand those who wax poetically about what a walk in the garden Ruby-on-Rails is. I came to it as an experienced ASP.NET-MVC, Java, PHP, Python developer -- and found it to be the most horrible time-waster ever! 90 percent of the online google-answers are wrong or incomplete. Why? Has it changed that much every single year? Or is it that nobody cares about making code actually work? It took me massive amounts of time to just do simple things; far, far more than it would take me in C#/ASP.NET-MVC, for example. It certainly never took me anywhere near that long to learn my original technologies. Granted, ROR is terse. If that's important to you. But I found it rarely clear how to create code that would accomplish a task. Personally, I would rather type on a keyboard for 20 seconds to write code that definitely works, is clear and you can follow it, rather than type terse Ruby code for 2 seconds, but which never works until I am up all night searching for some way to actually make it work. It is a horrible, stinking pile of dodo. Why? Is it that open-source (as in free) code, produces no incentives to make it a quality tool? Too many script-kiddies pumping revisions and modules and bad documentation into it? I don't know. But when I was finally able to escape that first Ruby-Rails project, I swore I'd never step into that mess again!
I suggest you look at indices rating the prevelance of different languages/scripts. Here is a link that might prove useful: popular professionaly used web-related languages.
This shows the relative popularity of web-related languages based on searches of online job postings.
I agree to some of the above answers about RoR, I've been developing applications with RoR for the past two years. Its really good with simple applications, CRUD (Create, Read, Update and Delete) operations works very well, its a boon for developing simple applications but is also its limitations. Though there are a lot of gems offers various advantages and ease of use, its basically it. Going out of the box will get you applications all twisted.
If you are a large team working on an application using RoR, work delegation can be hard to get away with.
