[kstrauser]

That's just not true. C (in the hands of average programmers) is limited because it's not very expressive. There's no way to say "these 40 things can be run in parallel" or "run these 200 things asynchronously" in a standardized way. Very clever compilers can infer some autoparallelization situations, but I'm not away of anything that can auto-async a project that's not explicitly written that way.

That's C's limitation: it can only be as fast as the compiler geniuses can make it, or as concurrent as its users can explicitly make it. Given that almost all computers where you care about raw performance are multiprocessing now, that's a huge deal. Languages with primitives like async/parallel map() are going to have a hard time keeping up with those that do.

Sure, you can write ultra fast code in C or assembly. The fastest way to do so might be to write it first in Erlang, Go, or Rust and reverse engineer it from the resulting machine language.

[comex]

Rust does not have any better builtin support for concurrency than C++ - well, it's supposed to be safer, but it doesn't have the kind of fundamental enabling features you're talking about. In fact, most of the tools I can think of that do sound like what you're talking about, like OpenMP, Cilk, etc., are based on C++. (Both Rust and C++ are likely to gain some sort of async/await support in the nearish future, but they're hardly unique in that respect.) Go has a runtime that makes it cheap to spawn lots of threads, but it's not doing any super high level optimization or abstraction either (quite the opposite). I don't know about Erlang.

[burntsushi]

rayon probably deserves a mention here: http://smallcultfollowing.com/babysteps/blog/2015/12/18/rayo...

(It's not built in, but that's a good thing IMO. :-))