なぜゴルーチンは識別可能な名前を持たないのか

Go routine context - golang-nutsより、Rob Pikeの回答:

One of the critical decisions in Go was not defining names for goroutines. If we give threads/goroutines/coroutines (TGCs) names or other identifiable state, such as contexts, there arises a tendency to push everything into one TGC. We see what this causes with the graphics thread in most modern graphics libraries, especially when using a threading-capable language such as Go. You are restricted in what you can do on that thread, or you need to do some sort of bottlenecking dance to have the full language available and still honoring the requirements of a single graphics thread.

One way to see see what this means: Long ago, people talked of a “thread per request” model, and honestly it was, or would have been, an improvement on standard practice at the time. But if you have cheap TGCs, there is no need to stop there: You can use multiple independently executing TGCs to handle a request, or share a TGC between requests for some part of the work (think database access, for example). You have the whole language available to you when programming a request, including the ability to use TGCs.

Like Ian, I have not read this paper, but I take it as a tenet that it is better to keep goroutines anonymous and state-free, and not to bind any particular calculation or data set to one thread of control as part of the programming model. If you want to do that, sure, go for it, but it’s far too restrictive to demand it a priori and force it on others.