"If a web app is spending most of it's time blocking for I/O, it's poorly designed. There's no reason that it can't be handling other requests while waiting for a DB response or a pipe"
If your request-handling logic is responsible for concurrent requests, your application (and the platform it runs on) is poorly designed. This belongs to a thread/process dispatch mechanism in the platform, not inside your app. When one thread waits for the database, I am sure the processors can be busy with other requests.
"Scaling Rails is a nightmare."
No. It's not. There is little reason for it to be. While I am no Rails expert (I use Django and was a Plone guy not that long ago), the scalability issues most people have happen because of RDBMS concurrency much more than any problem with Rails itself. Like I said before, that time spent waiting for the database to respond is time spent in the database working. It is incredibly rare to have a front-end having heavier usage than the database that feeds it.
If you want your applications to scale, design it around the database limitations. Use C, C++ (I would prefer ObjC), Java or Assembly if you want, but faster request processing won't get you past database scalability issues.
Using C* or Java will only push back your release date.
In my experience once you get over a few hundred thousand users and have tweaked your web server/proxy setup and tuned your database, you will still have major slowness and memory issues with your Rails code. I.e. it's usually not the database's fault.
Also you might want to look at the profile of the guy who said that rails scaling is a nightmare. I wouldn't use the word nightmare as I'd prefer to think my professional life story wasn't written by Kafka. But, I don't know anyone who has scaled a big Rails site and thought it was a pleasant or fun experience. Most guys who say that it's no big deal haven't really done it.
I will concede that, according to my very limited Rails experience, it generates a lot of database chatter when compared to hand-coded queries. Still, this is mostly a database scaling problem.
The beauty of the ORM is that you can replace the underlying layer without disrupting the code running on top or add fancy things like local memory caching or a networked memcached store. I insist that if your application was built from the start with this kind of issue in mind, it will be easy to scale it if and when the time comes. Until then, you are solving a problem you don't know you have.
This gets harder the lower-level your language gets.
If your request-handling logic is responsible for concurrent requests, your application (and the platform it runs on) is poorly designed. This belongs to a thread/process dispatch mechanism in the platform, not inside your app. When one thread waits for the database, I am sure the processors can be busy with other requests.
"Scaling Rails is a nightmare."
No. It's not. There is little reason for it to be. While I am no Rails expert (I use Django and was a Plone guy not that long ago), the scalability issues most people have happen because of RDBMS concurrency much more than any problem with Rails itself. Like I said before, that time spent waiting for the database to respond is time spent in the database working. It is incredibly rare to have a front-end having heavier usage than the database that feeds it.
If you want your applications to scale, design it around the database limitations. Use C, C++ (I would prefer ObjC), Java or Assembly if you want, but faster request processing won't get you past database scalability issues.
Using C* or Java will only push back your release date.