<p>I think I'm getting utterly confused. There is so much polarised dialogue around good and bad patterns with Go I feel like I've got absolutely no idea how to do anything....</p>
<p>Are there good open source examples of APIs, websites etc. that are high performing, with clear use of good design patterns etc with Go, so that I can reset my brain somewhat?</p>
<hr/>**评论：**<br/><br/>TheMerovius: <pre><p>Don't worry about it. Do what you think makes sense and let good patterns diffuse into your brain over time. Participating in projects with presubmit codereviews helps (for example go itself and the golang.org/x repos). Most of the discussion is quibbling on a very high level, i.e. no matter what you do in those cases, you will probably end up with something decent (and I say that as someone who participates in that quibbling <em>big time</em>).</p></pre>adam_0: <pre><p>There's also <a href="http://codereview.stackexchange.com/">the code review stack exchange</a> I just discovered the other day, if you want people to critique your technique.</p></pre>izuriel: <pre><p>I wonder how long before people start equating this one (with the same rules and functionality) to the unfairness and horrid environment that StackOverflow supposedly has.</p>
<p>Also, thanks for the share that looks really interesting.</p></pre>Ainar-G: <pre><p>(Just my opinion.)</p>
<p>Saying "mutex is bad" and "channels are good" is like saying "strings are bad" and "structures are good". They can't be good or bad, they can only be good or bad <em>for a particular task at hand.</em> If you need a mutex, you shouldn't try and shoehorn a channel-based solution. And vice versa, when a problem requires concurrent messaging, creating your own solution by building pseudo-channels with mutexes, conds, and slices is just silly.</p>
<p>As for OP's questions, the Go concurrency patterns slides have nice examples of how and when to use channels:</p>
<ul>
<li><p><a href="http://talks.golang.org/2012/concurrency.slide">http://talks.golang.org/2012/concurrency.slide</a></p></li>
<li><p><a href="http://talks.golang.org/2013/advconc.slide">http://talks.golang.org/2013/advconc.slide</a></p></li>
</ul></pre>LemurFromTheId: <pre><p>"There are only two kinds of languages: the ones people complain about and the ones nobody uses." – Bjarne Stroustrup</p></pre>lolomfgkthxbai: <pre><p>Quite so!</p></pre>dinkumator: <pre><p>Generalizations are bad! Except when they're good!</p>
<p>It's all about the right tool for the job. If you need huge throughput numbers you shouldn't rely on blanket statements, you should learn about the idiosyncrasies and tradeoffs of each technique.</p>
<p>Generalized statements are good when they help you understand complex systems at a high level, but bad when they are applied like a set of rules to every piece of software.</p></pre>TheMerovius: <pre><blockquote>
<p>Generalizations are bad! Except when they're good!</p>
</blockquote>
<p>I always say "all generalizations are wrong, including this one" :)</p></pre>bonekeeper: <pre><p>Benchmark. Repeat.</p></pre>random314: <pre><p>There are good and bad use cases for virtually everything in this world. Go channels and routines included.</p></pre>izuriel: <pre><p>First off, any article titled "X is bad" (or "X is good") need to be taken with a grain of salt. You're immediately given the information that you're about to read someone's opinion and the outcome they're complaining (or parading) may be that of an accident or misunderstanding. I've been guilty of barring something from my tool belt because I thought it was highly error prone only later to find out I was using it the wrong way and when used properly there was absolutely nothing <em>inherently wrong</em> with it. What does this mean? Read the article, really put some thought into the complains/praise and do your diligence. Blog posts and articles now-a-days are so easy to create you've got people from beginners (not that there is anything wrong with this) to experts writing posts about X and Y left and write, day after day that you have to be extra diligent about the accuracy of what you're reading.</p>
<p>I think it's great that we have such easy access to vast arrays of information because some people have ideas about how to use and/or do things I never would have thought. Other times I've seen reputable individuals who people implicitly openly speak against certain standard design patterns when the real meat of the article equated to "uneducated engineers don't use the pattern right, therefore the pattern is bad" which is so obviously false. A pattern is bad when there are no applications of it that improve performance, workflow, understand or any other common aspect of code and programs. The <a href="https://en.wikipedia.org/wiki/Bogosort" rel="nofollow">Bogosort</a> is a terrible algorithm for sorting lists of things. That is a provably bad pattern. And no point would it be useful or wise to use this algorithm to sort a data set.</p>
<p>Anyways, I ramble. <strong>tl;dr</strong> people are prone to ranting about things they misunderstand or dislike (or praise things they misunderstand or absolutely found extremely useful) but that, in itself, doesn't make those opinions the stone cold fact. Read and research what you learn, add to your what you need and understand and be careful when someone speaks in absolutes. Absolute truths are an impossibility.</p></pre>petulant_snowflake: <pre><p>Like everything in programming, there are right and wrong applications of any technology. It takes experience, wisdom, and a hundred thousand times doing it the wrogng way before you are able to identify and understand when something like a channel or goroutines are the right thing for the job. Even the best out there still make mistakes and will often go back and revise.</p>
<p>Knowing who to listen to also takes a lot of experience and knowledge in its own right, and is complicated by the fact that a lot of devs out there who are in the 60th percentile think they are in the 99th percentile and often post lame articles expressing outrage or disgust about tech XYZ. For instance the blog article that made the rounds yesterday about how channels and goroutines sucked. I read half way through the long winded post before I came to the conclusion the author knew basically nothing about properly building concurrent apps in Go and <strong>when</strong> to use that design/language feature.</p>
<p>Knowing kung fu isn't as important as knowing <strong>when</strong> to use kung fu.</p></pre>robertmeta: <pre><blockquote>
<p>There is so much polarized dialogue around good and bad patterns with Go I feel like I've got absolutely no idea how to do anything...</p>
</blockquote>
<p>Stop looking for silver bullets ("design patterns", "the one true way"). You have to be flexible and adapt your approach to your problem. Callbacks work for some problems, but you end up in callback hell on other problems. Channels are amazing for some problems (ETL) and worse for others. I actually haven't seen anyone really so goroutines or mutexes are bad... but, they aren't. </p>
<blockquote>
<p>Are there good open source examples of APIs</p>
</blockquote>
<p>The go standard library is your "go" to for examples of how to write go. </p></pre>mcouturier: <pre><p>My 2 cents here...</p>
<p>Whenever I read an article about something bad in Go, there's almost always a clear explanation why it is the way it is on the <a href="https://golang.org/doc/" rel="nofollow">official language website</a>.</p>
<p>I say, stick to the core documentation and its close surroundings like <a href="https://gobyexample.com" rel="nofollow">gobyexample.com</a> and follow their examples. Don't hesitate to get code reviews on the Go <a href="https://groups.google.com/forum/#!forum/golang-nuts" rel="nofollow">mailing list</a>. People there are awesome and always willing to help. Use the <a href="https://play.golang.org/" rel="nofollow">playground</a> to demonstrate to others what you are trying to do to get code reviews.</p>
<p>Go is awesome but also very opinionated. So that's normal that there are some polarized discussions around it. Take the good things, build on it.</p></pre>itsmontoya: <pre><p>Channels aren't as performant as they should be. That being said, they aid in constructing VERY idiomatic code which is still fast "enough". </p>
<p>For services where clean code is important and being fast enough is acceptable, we utilize channels a decent amount. In the situations where we need more speed than that, we use mutex's. Additionally, when we need even MORE speed, we work directly with the atomic library. </p></pre>mostlywaiting: <pre><p>I'd say that channels are great when you are using them to handle resources that may have significant latency. Then their overhead is not significant and the ease of use is a huge win.</p></pre>itsmontoya: <pre><p>Yes, this would be an example of a useful situation for channels</p></pre>sybrandy: <pre><p>I like this answer. I like reading the articles that do go into why X is bad, but in many cases the built-ins are good enough. I actually want to go back to some code I wrote to make it faster, but not because I need to because it's performed very well with channels. I just want to make it better.</p>
<p>Just like any other critical article, take it with a grain of salt. There's a chance it has some good info that can be useful. Just don't believe that all that is bad is really, truly bad.</p></pre>gruey: <pre><p>For statements are good! For statements are bad!</p></pre>f2f: <pre><p>learn rust. there's nothing bad there. until it all changes, and then the new thing is good and the old is not talked about in polite company :)</p></pre>jessegreathouse: <pre><p>I agree with half of those complaints!</p></pre>jasonrichardsmith: <pre><p>Seconded!</p></pre>
