And anything that is slow with just Ruby can be solved by throwing money at it.
To build apps that our users will love.
No matter the language, framework, or whatever. If we miss this point which is a very crucial point for that matter. Then all of our optimizations are for nothing.
Probably 1% of all websites on the internet ever manage to get enough traffic to make the language matter, right?
I understand why people use PHP, but as someone who has a decent amount of experience with a variety of languages, I really want a language that's designed sanely, especially for things like web-(sites|apps). I'll gladly take a hit on the language-speed side, or on the ease-of-finding-hosting side for the sake of not having to put up with PHPs craziness.
Why? For just the reason you pointed out - the vast majority of websites don't get enough traffic to make the language matter. I'd imagine that things like learning how to configure apache and/or a caching tool like memcached would handle most of the performance bottleneck on a site that did get that level of traffic.
Seriously - if a language is "fast" enough to allow the creation of responsive GUI apps, it's "fast" enough for web-apps.
put nginx in front of thin, start caching frequently used objects, and slice up your database and suddenly speed isn't a problem. php has the (perceived) advantage of running compiled in an apache module, typically. but it's a perception -- you have to do a little more tuning with your rails deployment to make it scream, but make no mistake, it can scream, even under heavy load, and without a huge server farm, at least up to 500K pages/day. i know that number because i've served it. quickly.
in radiant. (gasp! yes, with some caching.)
with one database.
it's a lesson i learned working with tomcat back in the day: defaults suck. learn your framework, learn your app server, pick the Right Thing. it's all about application tuning and app-server choice, and that goes for every language and platform in existence.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...
Avi Bryant did.
For small to mid-size web apps, I far prefer python and cherrypy (http://www.cherrypy.org). Easier to use, and easier to deploy assuming you have hosting that gives you control over your hosted machine (here's looking at you, slicehost).
As the webpage states "a white bar shows which language implementation had the better time, and a black bar shows which had the better memory use".
More flattery - in context "most" is not ambiguous, it's vague.
As you are saying how to read the graph, a specific example will be more helpful than a vague summary.
Outlying results have to do with that whatever that specific benchmark concerns, e.g. thread startup cost.
There are 2 which require threads, there's no PHP program for either of those so why do you think "thread startup cost" has any relevance?