"So far, only Rust has a good story on concurrency thanks to its type system." In the strongest sense of that phrase, Erlang and Haskell also have extremely st

"So far, only Rust has a good story on concurrency thanks to its type system." In the strongest sense of that phrase, Erlang and Haskell also have extremely strong concurrency stories, in that each in their own way, they forbid the most common mistakes. It's hard to compare which of these is "better" or "stronger" though since they all differ so much in how they approach the matter. There are a number of other languages that can make claims to having a reasonable "concurrency story" if you combine the language with certain practices, which permits writing concurrent code in a reasonable fashion (i.e., not a disaster of locks), but that technically aren't necessarily better than C. D may fit in there. It may sound vacuous to say this, because you could always just port those practices back to an older language, and indeed, you can, but the community default matters because of the resulting library support. (Prime case study: Twisted and Python, with the way Twisted required essentially its own version of many significant bits of Python functionality to work in its environment; it could never completely take off because it was at such variance with what the community did by default.) This class of languages is a more populated area, since it turns out while concurrent programming is never going to be completely trivial IMHO, the exponential complexity explosion of pure mutex-based systems that was such a disaster in the 1990s and early 2000s is more a problem of the primitives used to address the problem than the languages themselves. Mutexes are an invaluable tool, but not suitable as the "base" abstraction that programmers actually use.