http://developers.slashdot.org/article.pl?sid=07/12/17/1635200&from=rss
The point is that to make use of multiple way systems, aka machines with a mix of processors and cores, you have to put more thought into your designs.
I've always thought that perl, PHP, and to some extent Java came about because developers could write code in weakly typed/garbage collected systems faster.
Sure, Java is not weakly typed, but the way I see developers program with it, you would not know the difference.
These languages gave us tools to develop against systems that had plenty of memory. Until the advent of 32bit systems, you really had to watch the amount of memory you were using.
Memory issues Today?
"Not so much".
Memory is plentiful, and with 64bit systems becoming common this more true then ever.
Multi-way machines are a catalyst for a new language. One which is concurrent by nature (which might just mean it is map/reduce in nature... which is one of the simplest way to make use of concurrency). Whatever language, or languages, that provide concurrency through the simplest design will when.
I have an Erlang book on my Amazon Wishlist if anyone wants me to give an opinion on it :)
I wonder where my book on Occam is?
If I was designing a language today? I would target 32 processors. It will be common soon enough, and that is enough processors where problems with concurrency can be explored. The argument of "just do two" is pretty lame (and I am hearing that over and over).
Other lame things I am hearing?
Forking? Get real.
Global locks? Yeah, that is going to scale.
Something will come about. Who knows, maybe someone in China has already written it, and I have not heard about it yet because I do not read Chinese.
Back to coding... on MySQL... which is concurrent... using C++... which is not all that friendly for this problem.