In the Java programming language it is easy to see the evolution of the language:
- 1995: Support for threads built into the language (Thread, synchronized, volatile)
- Java5: Included java.util.concurrent (which adds a lot of nice to have classes when doing Thread programming)
- Java7: Talk about introducing frameworks supporting further multi-core usage
Well first and foremost I think that the new programming languages must have support to handle many-cores built into the language rather than adding these important features as APIs later on.
Another issue is that the new features in Java7 (e.g. fork-join framework) aims to solve problems that are a minute part of the overall problem. Let me give you an example taken from the article "Java theory and practice: Stick a fork in it, Part 1". In this well written article the fork-join framework is introduced to the reader and it is a very handy tool when used for the right problem. And this is the springing point: "When used for the right problem". In this case that is sorting. But let's not get into sorting with fork-join rather address the real problem: I/O.
In the article mentioned above the author (Brian Goetz) writes the following "Server applications normally run many more threads than there are processors available. The reason is because in most server applications, the processing of a request includes a fair amount of I/O which does not require very much of the processor" ... "As processor counts increse there may not be enough concurrent requests to keep the processors busy.".
From there on the article describes how to divide the parts that can be divided (sorting etc.) into sub-problems and solve them all in parallel.
I'd like to focus on the second quoted sentence above though. What Brian writes is basically that unless we solve the real problems (I/O) then there will be no way to keep our many-cores busy.
This means that there will be idle computer power but it will be impossible to improve the speed of the programs! What CTO will be comfortable with this? What architect would want to go into the board room explaining why the CPUs are more or less idle but it's not possible to handle the peak hour requests?
When this happens, and trust me it will happen sooner than we think, it will open up the ballpark to new languages. There has been a lot of buzz around Erlang the last 1.5 years, and there are good reasons for it. Just check out this comparison between Tomcat and Yaws (an Erlang based web server). I don't think Erlang will ever be a contender to Java in terms of popularity or usage, but perhaps other languages similar to Erlang will.
Scala is a programming language gaining momentum within the Java community. This language incorporates both functional and object oriented features. It could serve as bridge between the two camps and work as an eye-opener for all those hard-core-Java-will-prevail-and-survive-anything coders :-)
Only future will tell what languages we'll be coding in when many-core platforms are here. No one can be sure for certain, but I'd put my 2c on that Java (and C# for that matter) will struggle keeping the same attention from the IT community in a couple of years time.
What do you think?