> 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.
Erlang VM is actually design around full CPU utilization. It will typically spin up a thread for each core and schedule processes (Erlang not system) across them. It's actually because it's designed to not share memory that it excels at parallelism!
This design does not do well at CPU parallelism for many workloads. Consider texture sampling in rasterization, to name just one example, in which shared memory is extremely important to get good performance.
>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...
Once the revision is published I welcome more comments/corrections. I have never worked with Clojure and could easily be getting some part of what I write wrong.
The same place as the author's understanding of Moore's law.
(Moore's law hasn't broken, because it said nothing about clock speed, it talks about transistor density, and sure enough multi-core and lithography improvements have continued that trend).
> 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.