You make some fair points about practical scalability issues, and of course I agree with you on the points about multithreaded programming complexity in mainstream languages today. However, on the scaling side, I think you are getting sidetracked from the point I am trying to make. What I am looking at is how multicore will change how people write programs. The common contention is that we’ll all have to start looking for ways to parallelise our sequential code to take advantage of multiple cores.

Multi-user web applications, however, are parallel by nature. Multicore doesn’t completely change the game for these apps. The problems you talk about existed before the rise of multicore, as the largest web applications already used multi-CPU machines and many of them.

Web applications will naturally take advantage of more cores as they appear. The only programmers likely to notice the performance impact are those working in areas where performance has always been at the bleeding edge, which frankly is a small minority.

This will not happen. Open source Web applications are dominating the web and they are written using scripting languages like PHP, Ruby(with Rails) and ASP.NET. None of these will naturally scale without proding by the programmer. This requires thinking ahead to concurrency and scalablility but since the greater percentage of these apps are organically produced is not done.

Also since we are mostly in a place where web applications are the reason for the need of more porcessing power and speed Apache becomes one of the weak links. This is why I throw in Java with things like mod_perl, mod_python and the rest. They are one of the reasons that PHP is so popular with web hosts and why the cost of shared hosting for them is on average higher. Their usage requires more software and more administration to make sure things don’t go horribly wrong.

There are many technologies that are multi-threaded “by nature” but few that are multithreaded by design. It is this difference that make is hard to do multi-threaded programming and to use multi-threading as a solution to scalability. The same is true for concurrency.

There is also the script language or programming language short coming of being delivered through an interpreter or compiler that cannot do anything more than run a single process. Almost every attempt to get multi-threading to work with PHP, Java, Python and others has been an exercise in instability. This is why FastCGI is so popular nowadays and will become more popular.

You are right in saying multi-threaded programming is hard and requires a lot of planning and for thought before hand. So many will opt to use FastCGI and languages like Erlang where an application can be built using multiple single threads that can be distributed throughout a network and run as Light Weight Processes on those multi-core and SMP machines.

I have chosen to go the way of Erlang rather than FastCGI or learning to do LWP in ASP.NET. I think that Erlang has advantages over FastCGI in terms of administration, installation and room for improvement.