As with everything, it all depends on what you're doing with the app. If you're shooting to be the next myspace.com with hundreds of millions of users, RoR in its current implementation is going to give you some real headaches, so you'd better be sure it's worth the saved development time.
If you're never going to scale past a few thousand users, then, yeah, who cares?
The trend on the desktop is that the inevitability of faster hardware and more efficient runtimes almost always trumps perf problems introduced by the next-higher-level framework. Cocoa apps may have been dicey on an ancient G3 under 10.1, but those users age out without your help, and now users can't perceive a slowdown and the turnaround time for coding is still really good. The same mostly goes for .NET on Windows.
On a server, though, when everything's against the metal and you own the whole stack, time alone won't age out user base-- a RoR server that can handle only 20req/sec today (say) won't magically be able to handle 2000req/sec two years from now unless the box is either upgraded or the software on it is upgraded, both of which imply a very real maintenance/IT cost. If you multiply that across lots of servers, it gets even harder.
Ruby people are spending some time optimizing the Ruby runtime, and surely the Rails folks are doing the same. It's still a somewhat dicey bet for a service (less so over time), but it certainly makes a lot of sense for rapid turnaround/simple deploy stuff.
Besides, in this heady Web 2.0 world, sometimes making that tradeoff in favor of faster time to market is necessary just keep your company afloat *now*, even at the later significant cost of more hardware.
by Ben — Feb 06
If you're never going to scale past a few thousand users, then, yeah, who cares?
The trend on the desktop is that the inevitability of faster hardware and more efficient runtimes almost always trumps perf problems introduced by the next-higher-level framework. Cocoa apps may have been dicey on an ancient G3 under 10.1, but those users age out without your help, and now users can't perceive a slowdown and the turnaround time for coding is still really good. The same mostly goes for .NET on Windows.
On a server, though, when everything's against the metal and you own the whole stack, time alone won't age out user base-- a RoR server that can handle only 20req/sec today (say) won't magically be able to handle 2000req/sec two years from now unless the box is either upgraded or the software on it is upgraded, both of which imply a very real maintenance/IT cost. If you multiply that across lots of servers, it gets even harder.
Ruby people are spending some time optimizing the Ruby runtime, and surely the Rails folks are doing the same. It's still a somewhat dicey bet for a service (less so over time), but it certainly makes a lot of sense for rapid turnaround/simple deploy stuff.
Besides, in this heady Web 2.0 world, sometimes making that tradeoff in favor of faster time to market is necessary just keep your company afloat *now*, even at the later significant cost of more hardware.