Go is not an easy language
Going by their first example, the fact that I couldn&#x27;t write<p><pre><code>   list.delete(value)
</code></pre>
without realizing it involves a linear search is considered one of the benefits of Go.<p>That said, I agree Go could use a bit for ergonomic and handy methods, while still remaining efficient.<p>The example on Concurrency also has a different answer. Go gives you all the tools, but there are many different ways their problem can be solved. By explicitly avoiding a &quot;join&quot; method and having any default &#x27;channels&#x27;, Go makes all these possible. What is missing is some of the popular patterns that emerged in the last few years need to make it to into stdlib or some cookbooks.<p>1. If you want a worker model, I would start n=3 go-routines and they all receive from a single channel. They don&#x27;t need to much around with a channel of buffer 3, as in the example.<p>2. If the workers already return data from a compute, the read from driver serves as the wait.<p>3. In other cases, there is sync.Waitgroup available to synchronize completion status.<p>4. End of work from the driver can be indicated via a channel close. Closed channels can still be read from until they are empty and the reader can even detect end-of-channel.<p>Designing concurrent system is a bit complicated. Some tutorials do make it sound like a `go` keyword is all you need. All of these can fixed by improving std-lib or cookbooks.