One should remember that not all problems can be solve faster with concurrency - not all problems are "embarrassingly parallel". Besides, even when they are, on

One should remember that not all problems can be solve faster with concurrency - not all problems are "embarrassingly parallel". Besides, even when they are, one gets diminishing returns by adding more cores. Raw performance on single core is still relevant. That said, support for concurrency is relevant but more for "masking" I/O latency than for MIPS, a problem which is apparently more common. For a language created after 2010, it is nearly a fault not to have something less primitive than threads to handle concurrency. It is like still manually managing memory manually like C also does. I agree that "faster than C" claims too often hides some kind of cheating. But we have HN "reviewers" for that ;-).