<p>I just started looking into golang and have a question about the design of goroutines.</p>
<p>In Go we have a special keyword -- 'go' -- for spawning a new goroutine.
Why do we need a special keyword and language support for spawning goroutines?
Couldn't goroutines be just as easily implemented as a library?</p>
<p>My thinking is that there could be a library, for example modelled after pthreads, but instead of spawning OS threads it would manage goroutines and schedule them to OS threads in much the same way as the Go runtime does now.</p>
<p>I think such a library could even be implemented for other languages. I also found libdill (<a href="http://libdill.org/" rel="nofollow">http://libdill.org/</a>) that seems to do just that for C.</p>
<p>Does anyone know what the reasons for designing a special language construct for goroutines are?
Are there any advantages of having the 'go' keyword as opposed to having a library manage goroutines without special language support (such as libdill)?</p>
<hr/>**评论：**<br/><br/>gratator: <pre><p>I think the main reason here is simplicity and 'futureproofness', you as a programmer know what/how X can be parallelized, then you don't need to know what computer you are running on and any performance optimisations since this will be language specific.
Then your program will also be able to adapt to most machine type and use the most if its resources without the need of optimizing.</p>
<p>Here's a nice video about it: <a href="https://www.youtube.com/watch?v=cN_DpYBzKso" rel="nofollow">https://www.youtube.com/watch?v=cN_DpYBzKso</a></p></pre>babypistol: <pre><p>I can see that having goroutines as first class citizens in a language does promote writing concurrent applications. However, it promotes a specific model for concurrency (namely goroutines).</p>
<p>From the article [1] it seems that there might be better ways of managing concurrency than goroutines. </p>
<p>By choosing to implement goroutines as first class citizens in Golang it seems to me that the developers have needlessly cemented a model for concurrency into the language that might not be the best. If it were a library someone could make an alternative library using a different model.</p>
<p>The goroutines model might turn out to not be the best model for concurrency and it will not be possible to change Go to use a better model.</p>
<p>Because of the problem that first class features in a language a very hard to change in the future I was thinking that there must be a very good reason to bake goroutines directly into the language and thus inhibit developing alternative models for concurrency in Go.</p>
<p>[1] <a href="https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/" rel="nofollow">https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/</a></p></pre>icetheace: <pre><p>Would have to agree. First class means you know your environment variables already and so does the engineering of the language. </p></pre>ui7_uy8: <pre><blockquote>
<p>Why do we need a special keyword and language support for spawning goroutines?</p>
</blockquote>
<p>And why do we need goroutines as a library? the whole point of Go is first class concurrency. There is no point using Go if it behaves like C. Something implemented as a library is not first class.</p></pre>babypistol: <pre><p>Sure there is no point in using Go if it behaves like C. But it does not, it has many advantages over C other than goroutines.</p>
<p>I was just thinking that there must be a reason for choosing to make goroutines first class.</p>
<p>Usually there are some technical reasons for making such a decision, e.g., first class functions allow for creating closures and passing funcrtions as arguments.</p>
<p>In the case of goroutines I don't see any (technical) difference between having it implemented in a library or a first class feature. And in my opinion having a choice between an (equally capable) language feature and a library we should opt for a library, because it is a more conservative choice that allows for more updates in the future and leaves the language more general.</p></pre>Killing_Spark: <pre><p>I think you are right that there is no technical benefit for either option. But the go keyword is a pretty good unique selling point for the language so thats probably good. </p></pre>
