You make some interesting points, and I agree that C++ would not be the choice in all situations. I would extend this to say that it would mostly only be really efficient to use in transactional applications. In other words, when you need ultra high performance transactions of information that may bubble to high bandwidths. An example of this would be Twitter's usage of the Scala programming language (which runs on the JVM) in replacement of Ruby for the queuing system which transacts data between the front end and the server daemons [<a href="http://www.artima.com/scalazine/articles/twitter_on_scala.html">Twitter Uses Scala</a>]. Although they did consider C++ for this responsibility, in the end they went with a language that had a "better feeling" to them, if for no other reason. For those who feel most comfortable with C++, it would make an excellent choice for these types of transactions.
On the other hand, an ordinary scripting language or framework like PHP, RoR, Django, etc, is fine for most situations, even massive sites, because content can be statically cached, served straight from the file system or a simple SQL query, bypassing all or most of the business logic altogether. No amount of C++ power will be faster than a static page. This type of optimization is very easy to implement, and requires so little code it doesn't matter what is used to write it. The only trick is knowing when to clear the cache so that users are seeing the newest available content. C++ might be handy if there is a portion of a page that has a constantly updating portion via a recurring AJAX call, and this page has a huge amount of requests being made to it. This is a simple example of what I mean by transactional data.
Other than these points, most of the slowness on a website happens on the client-side, not on the server-side. If a framework addressed front-end issues like Rails does, it would have to be very sensitive to the many things that can slow down the user, since there are so many factors, from the number of HTTP requests to the nature of JavaScript being requested, to whether JavaScript is being kept externally, etc, etc. I don't see C++ as being of any particular advantage on the front-end, since serving a web page is so straightforward. If a framework like this is to succeed it needs to first do what it should be able to handle best: In addition to making SQL calls, it should be able to handle simple HTTP requests with ease, send headers, then return data in widely accepted mediums; JSON and XML should be standard options for output. If you start with a core transactional framework you can move to other things later, like a template system.
PHP or Python with C++ transactions would be very cool.
Sept. 22, 2009, 5:04 p.m. - Abel Mohler
You make some interesting points, and I agree that C++ would not be the choice in all situations. I would extend this to say that it would mostly only be really efficient to use in transactional applications. In other words, when you need ultra high performance transactions of information that may bubble to high bandwidths. An example of this would be Twitter's usage of the Scala programming language (which runs on the JVM) in replacement of Ruby for the queuing system which transacts data between the front end and the server daemons [<a href="http://www.artima.com/scalazine/articles/twitter_on_scala.html">Twitter Uses Scala</a>]. Although they did consider C++ for this responsibility, in the end they went with a language that had a "better feeling" to them, if for no other reason. For those who feel most comfortable with C++, it would make an excellent choice for these types of transactions. On the other hand, an ordinary scripting language or framework like PHP, RoR, Django, etc, is fine for most situations, even massive sites, because content can be statically cached, served straight from the file system or a simple SQL query, bypassing all or most of the business logic altogether. No amount of C++ power will be faster than a static page. This type of optimization is very easy to implement, and requires so little code it doesn't matter what is used to write it. The only trick is knowing when to clear the cache so that users are seeing the newest available content. C++ might be handy if there is a portion of a page that has a constantly updating portion via a recurring AJAX call, and this page has a huge amount of requests being made to it. This is a simple example of what I mean by transactional data. Other than these points, most of the slowness on a website happens on the client-side, not on the server-side. If a framework addressed front-end issues like Rails does, it would have to be very sensitive to the many things that can slow down the user, since there are so many factors, from the number of HTTP requests to the nature of JavaScript being requested, to whether JavaScript is being kept externally, etc, etc. I don't see C++ as being of any particular advantage on the front-end, since serving a web page is so straightforward. If a framework like this is to succeed it needs to first do what it should be able to handle best: In addition to making SQL calls, it should be able to handle simple HTTP requests with ease, send headers, then return data in widely accepted mediums; JSON and XML should be standard options for output. If you start with a core transactional framework you can move to other things later, like a template system. PHP or Python with C++ transactions would be very cool.