views:

613

answers:

8

I was looking at a SO member's open source project. It was a web framework written in C++.

Now you are all probably ready to respond about how C++ is a horrible language to do websites in, and that in websites, the bottleneck is in the database.

But... I read this post:

http://art-blog.no-ip.info/cppcms/blog/post/42

and in there he makes the case that in a large site such as Wikipedia, the database servers only make up 10% of all servers. Therefore C++ would be better than languages like PHP Python Ruby C#.

Are his points valid?

+8  A: 

Servers are a one-time fixed cost of a few grand. Programmer time costs a lot more than that. Sure, writing websites in C++ would reduce hardware costs, but would greatly slow down development. So if you can shave one man-month of time off your development by using Ruby instead of C++, that pays for an extra server.

Better means a lot more than "faster".

Tim Sullivan
Don't you have to factor in upgrade/datacenter rent/electricity costs?
Unknown
Sure, but they're still less than programmer time costs.
Tim Sullivan
There is additional significant problem: good scaling required very good programming skills. Planning all cache system, DB and more requires very qualified stuff. For Django/PHP/Ruby project you would need spend much more time on architecture design of distributed system, when C++ would still run on signle multi-core server or probably two. Not talking about server administration costs: security updates deployment and so on.
Artyom
What a load of crap. 1) Distributing web applications isn't that hard. 2) By your argument, you should only write web applications in straight-up assembly code! 3) Good, bug free C++ takes very good programming skills, too, moreso than installing an application onto another web server and setting up a load balancer. Me, I'll take the significant increase in productivity, allowing me to improve my application over time spent compiling any day of the week.
Tim Sullivan
@Tim Sullivan: agreed and not only that: I'll buy 4 servers making 3 of them squid/memcache servers and one a database server instead of having to buy say 8 database servers.
Van Gale
+2  A: 

There are so many more problems that you face when writing in compiled, statically typed languages like C++, and these can all affect development. Some of the primary reasons scripting languages like Ruby or PHP have been invented is so that us a programmers can get more efficiency out of the language and toolsets we work in.

Yes, websites would be faster if they were written in a language such as C++. Yes, they could serve more people, be more scalable and be more efficient. But is this good enough reason to lose out on all the benefits that interpreted languages give us? Programmer happiness, development time, ease of use, portability, and so many more I can't mention.

The right tool for the right job, and for C++, website development isn't one of them.

Jamie Rumbelow
+2  A: 

I would be reluctant to say that servers are a one time cost of a few grand since some cost hundreds of thousands and I would venture to say millions. A number of sources will suggest that the biggest cost to the IT industry is hardware, not manpower. But for a comparison of the languages we need to compare them, not hardware.

The idea behind languages like Ruby, Python, PHP, and Groovy is essentially Rapid Application Development (RAD). The frameworks, Ruby on Rails, Django, CakePHP, and Grails are there to better facilitate RAD. The languages are easy to use and enable developers to setup and develop with little cost and the timeline involved is reduced in comparison to other languages or setups.

Is it right or wrong? It's all personal opinion but in the end the needs of the project will define which tool set is best suited. If your application has low traffic and you want to have it developed and live in a few months then it would be ideal to use one of the previously mentioned languages and/or framework.

But what about C++, .Net, and J2EE? Theres a place for everything. These tend to have higher up front costs associated with the time and energy to architect the project, setup the development environment, and do the actual development. But the languages and frameworks built from them are better suited for scalability to accommodate heavy traffic or computations.

Look at Facebook as an example. The original site was prototyped and deployed as a PHP application and the user base was relatively small. As the site grew into the monster we know it as today they scaled their application by implementing J2EE on the back end while using the existing PHP scripting for the front end.

As someone with experience in J2EE development and Python/PHP there is a very apparent set of advantages and disadvantages. I can build a blog with PHP in a few days ready for public access but the same project in J2EE may take much longer.

Forgive my terminology but Enterprise languages (J2EE, .Net) require a significant amount of configuration and deployment efforts. Ruby, PHP, and Python do not, you simply open Notepad, write your code and save it with the correct extension and you're ready to upload.

Does that help?

Doomspork
Where does it say Facebook has gone to a J2EE backend?
Unknown
Also, does this mean that well largely distributed applications like Wordpress should have been written in C++?
Unknown
"I would be reluctant to say that servers are a one time cost of a few grand since some cost hundreds of thousands and I would venture to say millions." The LAMP philosophy is all about deploying on low-cost commodity hardware, the logic being that one hundred $1,000 servers can get a lot more done than a single $100,000 server.
Frank Farmer
@Unknown At the time I was job searching and in contact with recruiters it was pointed out that Facebook was looking for J2EE experienced developers for their backend development. Currently their careers list C++, Java, or PHP knowledge for backend
Doomspork
@Unknown No it does not because the application itself is being distributed and therefore each individual setup is responsible for it's own server load. It being built in PHP makes it much easier to distribute to individuals using hosting services
Doomspork
@Frank 100 * $1,000 is still $100,000. $100,000 > "a few grand"
Doomspork
+1  A: 

Programmer happiness, development time, ease of use, portability, and so many more I can't mention

In fact... it is not so horrible and slow process to develop in C++, given right tools.

The Wiki that this project runs was written and up in few days (and yes, in C++)... Not bad for horrible C++ language ;-)

Take a look:

I think this is not a slow process for work at evenings to create such wiki: http://art-blog.no-ip.info/wikipp/en/page/main

Artyom
A: 

last I checked, php, Ruby, and Python are all written in C. Doesn't that count?

Up
No it doesn't count.
Unknown
+11  A: 

The problem with the article you link to is that the author clearly doesn't really know what he's talking about when he asks where the "bottleneck" is; the fact that someone has more web servers than database servers doesn't mean "the database can't be where the problem is". What's generally meant by "the database is the bottleneck" is the same thing that's been learned by everyone who ever does run-time profiling of a web application.

Consider an application which takes half a second to return a full response. Suppose you sit down and profile it, and find that that half second of processing time breaks down as follows:

  • Parsing incoming request: 50ms
  • Querying database: 350ms
  • Rendering HTML for response: 50ms
  • Sending response back out: 50ms

If you saw a breakdown like that, where database queries constitute 70% of the actual running time of the application, you'd rightly conclude that the database is the bottleneck. And that's exactly what most people find when they do profile their applications (and, generally, the database so completely dominates the processing time that the choice of language for the rest of the processing doesn't make any difference anyone will notice).

The number of database servers involved turns out not to matter too much; the famous quote here is that people like the author of the post you've linked are the types who hear that it takes one woman nine months to have a baby, and assume that nine women working together could do it in one month. In database terms: if a given query takes 100ms to execute on a given DB, then adding more DB servers isn't going to make any one of them be able to execute that query any faster. The reason for adding more database servers is to be able to handle more concurrent requests and keep your DB from getting overloaded, not to make isolated requests go any faster.

And from there you go into the usual dance of scaling an application: caching to cut down on the total time spent retrieving data or rendering responses, load-balancing to increase the number of concurrent requests you can serve, sharding and more advanced database-design schemes to keep from bogging down under load, etc., etc.

But, you'll note, none of this has anything whatsoever to do with the programming language in use because, once again, the amount of time spent or saved by other factors grossly outweighs the amount of time gained or lost by a "fast" or a "slow" language (and, of course, there's really no such thing; so much depends on the problem domain and the skill of the programmer that you just can't have a meaningful general comparison).

Anyway, this is getting kind of long and rambling, so I'll just wrap it up with a general guideline: if you see someone arguing that "you should build in Language X because it runs faster", it's a dead giveaway that they don't really know anything about real-world performance or scaling. Because, after all, if it just came down to "write in the fastest language", they'd be recommending that we all use assembly :)

James Bennett
+1 and to reinforce your argument about the author of the blog: the point of all those squid + memcached + "other servers for static content" is specifically to keep as much traffic as possible away from the database servers.
Van Gale
+1  A: 

No, his points aren't valid. It isn't that one is better than the other, but take C# and java for instance, they're just more advanced modern languages that have been designed with C++'s problems in mind.

It doesn't make any sense to bother with things like garbage collection if you don't have to. Also the various web framework languages have so many components, controls, modules, and many other pieces, open source or otherwise, already written for them by other developers, you would be reinventing wheels that exist in other languages, all over the place.

I'll always have a place in my heart for C++, but it's kind of idiotic or troll-worthy to suggest your better off writing websites in C++.

(EDIT: Maybe if C++ is the only language you know, or you have a lot of self-made components in C++ for the web, but your still probably better off learning a C++ descendent language for websites development, which are pretty easy to learn once you know C++/C)

Mark Rogers
A: 

His points are NOT valid for 99% of web applications. Web applications benefit from rapid iteration and friendly interfaces, both of which are better achieved with languages like PHP, Python and Ruby. If you are good or lucky enough to develop a highly used service, you will have little trouble engineering it to scale.

pbreitenbach