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 - that a

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 - 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 words 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 create pointless friction. 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 this article is engaging with a valid debate, and to pick it apart on sloppy use of a word is to miss the point.