in a massively multicore world, parallelism is more important than concurrency, and the two are not the same I think you're right in a technical sense - parall

in a massively multicore world, parallelism is more important than concurrency, and the two are not the same I think you're right in a technical sense - parallelism is indeed the great goal, and that article used the term slightly sloppily. However, the degree of parallelism in a program is limited by the ability of the human author to cope with all the concurrent interactions. So fundamentally, the two boil down to the same problem. One approach - that taken by Erlang and (from what I understand) Haskell - is to force people to write programs in a special way (pure message-passing or pure-functional), such that they become (almost) embarrassingly parallelisable. Another approach - that taken by Scala, and my personal favourite, Clojure - is to keep the existing paradigm (JVM threads in both those cases), and encourage people to write large parts of their program in styles which make concurrency easier (Actors, STM, immutable values, and so on). There's something to be said for both approaches: Erlang- or Haskell-style "purity" keeps you well-behaved, and gives you a lot more parallelism "for free". On the other hand, there are processes, tasks and other systems which are fundamentally sequential or mutable, and forcing you into conceptual backflips to cope with this can grate. I don't mean to put one approach above the other - and I'm aware that my summary is woefully inadequate - but I do believe it's a valid debate this article is engaging with.