There is some background in the first blog post on the topic:<p><a href="http:&#x2F;&#x2F;250bpm.com&#x2F;blog:69" rel="nofollow">http:&#x2F;&#x2F;250bpm.com&#x2F;blog:69</a><p><i>I guess it made sense from performance point of view back then. All the stuff that makes process switching slow today haven&#x27;t yet existed. Machines had single processor, there was no virtual addressing or memory caches. In such an environment process switching was closer to what we call green threads today.</i><p>So he is referring to hardware changes that made processes relatively more expensive than they used to be.  I would think that the old machines still incurred some hit from a state change in the MMU.  But I am far from an expert in  that area.<p>Also, this statement seems suspect, because multiple cores properly used can make processes CHEAPER.  Because there will be ZERO process-switching cost -- you have parallel processes.  This is why I advocate an architecture based on heterogeneous threads or processes and message passing -- in contrast to process-per-connection, which implies homogeneous processes and little message passing.<p>The Go designers also advocate heterogeneous goroutines, toward the goal of program modularity rather than performance.<p>If you have heterogeneous threads&#x2F;processes pinned to cores, that&#x27;s pretty much the most efficient way of using your hardware.  But writing this type of code is not so obvious without some planning, foresight, and working around language quirks.