I wish I could give you a 1000 up-votes for this. I'm so sick of hearing the rhetoric about language X not being able to scale.
Repeat after me, if your app doesn't scale it is YOUR fault, not a language, platform or framework. Scalability is about design and implementation, not what tools you use.
When you start out, you're designing your site in hopes that someone other than your mom is going to use it. Usually, all you need is an app server and a database. I you get successful, that won't cut it. You usually need to start adding more and more pieces and rethink some technology decisions you made originally.
I think I understand why the initial design/technology decisions would rarely make it to a product that has to be largely scaled. This makes perfect sense for almost all cases.
Do you think that there are technologies that are inherently more scalable than others, so if some body was initially choosing them would stand more chances to scale up in a non painful manner?
Worry about the "nobody cares enough" problem long before worrying about the "oh crap, too many people care" problem. User apathy, aka "not enough traction" kills far more startups than inability to scale. Pick the ecosystem with which your company will be most efficient and agile, and cross the scaling bridge if you come to it. We've rewritten substantially all parts of our codebase and key infrastructure 2 or 3 times in the last 8 years. You'll get the pleasure of doing the same iff you have users...
I completely agree with you. I think that in the 99.99% of the cases the question of scalability is related with a pseudo-problem or at best a good problem to have.
Bear in mind that developer experience and smarts count for more than anything else (if you don't have those yet, don't worry - they will come with time, patience, and effort).
That said, I would say that languages and technologies that help you achieve a more modular design will help you scale more. This makes it easier to tear things out and move them around so you can alter your architecture much more easily than you would otherwise. And of course efficiency (in terms of code performance) doesn't hurt either, but I wouldn't choose something on that alone. If you can have efficiency and modularity, so much the better!
It was Rails and, it wasn't that it wasn't unscalable but because they did it wrong then, they hired a bunch of developers that knew nothing about Rails, so of course they moved a lot of new and core development to other technologies.
It also had a lot to do with the fact that at the time Rails sites mostly ran on lighttpd or Mongrel, which was notoriously crashy (god was originally invented just to restart crashed Mongrels). From what I understand, at the time ActiveRecord hadn't yet been rewritten in C, which was also a big bottleneck for them (not to mention trying to scale MySQL to an insane level of traffic).
Nowadays, we have fancy stuff like Resque for background jobs, Passenger (aka mod_rails) for serving up Rails content, and a plethora of NoSQL databases.
ActiveRecord was never rewritten in C. Twitter's problems stemmed from the fact that they had written a realtime messaging system, but designed it like a microblogging platform. The design wouldn't have scaled well, regardless of the technology they used.
