The point to understand here is that Go uses lightweight concurrency and has a layer of indirection between goroutines and hardware threads.  Goroutines allocate a tiny stack and Go uses a software scheduler to jump between routines. Then that Go scheduler starts hardware threads as workers to start executing the routines.<p>The net result is that Go is relatively efficient for naive programs that start hundreds or thousands of threads and let them all run.<p>I don&#x27;t know Scala or Erlang, but based on the results I would assume both are allocating a posix thread for each thread in the software and so it is using the kernel scheduler to switch between them with all the overhead that entails.<p>But a program can be refactored in all the languages to have a smaller number of workers and a queue of work to be consumed.  This would be faster than the Go version, but require more code and complexity.<p>I have been considering threading in Rust vs Go and that is the biggest difference I see between the approaches. However it should be possible to implement Go style goroutines in Rust using custom dispatch code like old C coroutines. I think I have already seen libraries like that, but I haven&#x27;t dug in the details to know for sure.