Erlang runs about K threads where K is the number of cores towards the OS. All processes are "logical" in the same memory space and usually they happen to be pr

Erlang runs about K threads where K is the number of cores towards the OS. All processes are "logical" in the same memory space and usually they happen to be pretty small with a heap of a few kilobytes. As long as this is the case, then even swapping among a number of threads, say 100, will not take you out of the 2nd level cache. If you have a large number of processes, then it is a problem. And do note that Erlang programs have way more pointer-redirections than a typical array-like approach which is common in Go and other imperative languages. That is the memory pressure by default will be higher than what you can achieve in languages with static types. It tends to be a problem for tight computational kernels, and Erlang programmers usually fall down to C if they prove to become bottlenecks. I have an older post here describing the schedulers: http://jlouisramblings.blogspot.dk/2013/01/how-erlang-does-scheduling.html http://jlouisramblings.blogspot.dk/2013/01/how-erlang-does-s... which is still reasonably up-to-date to give the overview.