> I think you should read the M:N scheduling links. I think this bears emphasizing. Slow language runtimes, like Erlang's beam.smp, can get away with using M:

> I think you should read the M:N scheduling links. I think this bears emphasizing. Slow language runtimes, like Erlang's beam.smp, can get away with using M:N threading because the overhead elsewhere is so high. However, once you're dealing with languages implementations which are reasonably performant, which includes Go, M:N threading has problems which suddenly surface above the waterline. This includes various inefficiencies due to two schedulers fighting each other, significantly reduced system observability, and bizarre runtime behaviour (again, due to two schedulers fighting each other). If the ability to understand and maximize performance matters, M:N threading is a disaster. We've been down the M:N road before for efficient systems (Solaris, Linux, the *BSDs, and others). Those implementations -all- died. Now Go (and Rust, both amazingly and depressingly) have resurrected this. I can only hope that the programming abstraction niceties that Go takes advantage of are worth the performance tradeoff, because there is a definite tradeoff.