The philosophies of software languages, from Go to Elixir

> To take full advantage of multicore processors, a programming language needs to provide mechanisms for concurrency…All of the languages in this chapter—Go, Rust, Kotlin, and Elixir—were specifically designed to address this need for concurrency.

This confuses concurrency and parallelism. All of these languages have support for I/O concurrency. But the CPU parallelism support varies significantly. Go is fairly bad at such parallelism, because it doesn't have generics for concurrent data structures, parallel iterators, etc. Rust has pretty good support for it, with Rayon and Crossbeam. Kotlin does too, since it inherits the Java ecosystem, including the excellent java.util.concurrent package. I'm not sure about Elixir; my understanding is that the Erlang VM is not really designed around shared memory, which limits the potential for CPU parallelism.

>Some readers will question why this chapter doesn’t include Scala. Although it’s a language that has great support for concurrency, its original guiding philosophy was more centered in functional programming. Kotlin, however, which was inspired by Scala in a way, does have a specific focus on concurrency.

Something similar can be said about Kotlin: The main design goal is the two way interop with different platform APIs (JVM, JS, LLVM). And of course it has many features a modern general purpose language is expected to have. Specifically for asynchronous progamming it has coroutines. However, I think for asynchronous and parallel computing Scala and Clojure have more to offer...