(I'm a full time Ruby/Rails programmer, and I have been for five years.)
There's a major flaw in the R/R culture: they have no interest in maintaining stable APIs. If you want to upgrade your Rails app to the latest version of some library, you might as well do a rewrite of your entire app. So many of the APIs change from release to release that most of your gems will stop working unless you upgrade. When you upgrade the gems, your code will stop working, because most of the gems will have changed their public API. If you've got a non-trivial application, you will essentially be unable to upgrade. You will stop getting security updates. What minor upgrades you can manage to do will leave things partially broken, and you'll just get used to it being broken. (for example, one project I've worked on is stuck with a brain-damaged RSpec library that reports error messages without interpolating the strings, you always get "Expected CONDITION, got FAILURE, see CODE" in the logs)
My recommendation: only use Rails for short term projects that will be completely shut down after a few months.
I know that it's common wisdom that "no ruby engineer will ever want to switch to java", but that's because you've never been saddled with a 2-year-old rails project (or a 5-year-old plain-ruby project, which will have the same symptoms, just more slowly). Then your team will be begging for something that runs its test suite quickly, that has enough static analysis to know if you're using an outdated API, that has a decent metrics library, where you can query the state of the VM, that doesn't constantly leak memory, that plays nicely with databases that have real constraints, that has fewer race conditions in common libraries, etc etc etc.
This is sadly too true. We have over a dozen Rails apps that need indefinite maintenance and we end up specifying explicit gem versions and/or burning lots of time just staying current. Still, it's better than everyone doing their projects in ad-hoc PHP.
Node is no panacea, but that's not quite true about stable APIs. npm is great about maintaining separately versioned libraries and reducing conflicts.
In your package.json can specify what version of a library to use and npm mostly figures it out for you. For instance, I'm still intentionally using an older version of Express (2.5.9 instead of 3.0.x) and npm hasn't had a problem figuring out deps.
Part of the reason this works is that the npms you install are kept in the local folder, not stored globally as many other package managers do, so some other random app on you box won't trample your delicate library configuration.
sure, but, if you chose to upgrade to Express 3.0.0, would your application still work? or are all the method signatures in Express 3 different from Express 2.5 ?
I do understand the need to refactor and clean up code, however, there is a lot to say for at least deprecating things for a very long time as I find the current RoR far too volatile like you say. Unless you are doing prototypes, short lived sites OR have a fulltime team on it all the time (who upgrades to every small increment of every lib and fixes/refactors/tests the entire project), I don't like it so much. I have done and supported RoR projects and it really takes out the initial wins when you sit swearing behind your monitor because even trivial libs (for which, in fact, you already had to resist the urge not to roll your own) stop working after installing the latest and the greatest. Sure, then don't upgrade to the latest; for a lot of things that's not an option (security would be one, needing another feature this new gem has is another) and it should just give you a nudge 'this is deprecated, please fix' warning for the next year+ instead. If you didn't fix it by then, then at least you were warned plenty in advance.
There's a major flaw in the R/R culture: they have no interest in maintaining stable APIs. If you want to upgrade your Rails app to the latest version of some library, you might as well do a rewrite of your entire app. So many of the APIs change from release to release that most of your gems will stop working unless you upgrade. When you upgrade the gems, your code will stop working, because most of the gems will have changed their public API. If you've got a non-trivial application, you will essentially be unable to upgrade. You will stop getting security updates. What minor upgrades you can manage to do will leave things partially broken, and you'll just get used to it being broken. (for example, one project I've worked on is stuck with a brain-damaged RSpec library that reports error messages without interpolating the strings, you always get "Expected CONDITION, got FAILURE, see CODE" in the logs)
My recommendation: only use Rails for short term projects that will be completely shut down after a few months.
I know that it's common wisdom that "no ruby engineer will ever want to switch to java", but that's because you've never been saddled with a 2-year-old rails project (or a 5-year-old plain-ruby project, which will have the same symptoms, just more slowly). Then your team will be begging for something that runs its test suite quickly, that has enough static analysis to know if you're using an outdated API, that has a decent metrics library, where you can query the state of the VM, that doesn't constantly leak memory, that plays nicely with databases that have real constraints, that has fewer race conditions in common libraries, etc etc etc.