>>782
逆に言えばそれ以外の環境では他言語に劣るわけだろ。

元々は多分、命名からして、コルーチンをgoroutineで、ということなのだと思う。
コルーチンは通常は本体側と交代で間欠的に動作する前提で書かれているから、スレッドで切り離すことはしない。
ただ、もしそれが本体と並行に動作可能なら、スレッドとして切り離せば、
本体側が動いている間に次のyieldまで動作させられ、コルーチン部分の処理時間を見た目ゼロに出来る。
実際、大半のコルーチンはこれが可能なはずで、これまでは単に面倒/スレッド生成消滅のコストの為にそこまでやらなかっただけ。
だから、スレッドよりもっとお手軽で軽いgoroutineを用意すれば、という訳だ。

OSでの並行はprocessだが、multi processは重すぎるのでアプリ内processとしてthreadが出来た。
それと同様に、thread内の並行として、goroutineという、もう一段軽い物を用意した。


だからここまでのストーリーは辻褄が合っているとして、それがどこに適用出来るかだよ。
CPUが精々数個しかないそこら辺のPCだと、threadだけで埋めきれるので、普通にそれが最適解になる。
threadだけでは埋めきれないほどのCPUがあり、積極的に並行goroutineとして切り出してくれないといけない、
という、いわゆるメニーコアならGoの方が有利になる可能性があるけど、実際この場合はキャッシュコヒーレンシの問題が発生してくる。
勿論チャネルだし、後はオブジェクトの中身も含めてインミュータブル、
つまりErlangの世界まで行けたらこの辺の問題も無くなるけど、Goはそういう感じじゃないでしょ。
そもそもメニーコアの筆頭のXeonPiも死に体だし。(これはGoのせいではないけど)