<p>I haven't found much tutorials about generic Go programming, could you guys explain for me how that works ?</p>
<hr/>**评论：**<br/><br/>jlund3: <pre><p>My first gut reaction was: Go doesn't have generics. We use interfaces for generic algorithms and type assertion/reflection for generic data types. Then I thought: Go <em>does</em> have some generic data types (i.e., maps, slices, channels and arrays). This got me thinking...how <em>do</em> generics work in Go for the few generic types we have? Does anyone have any information on this? Would this be a place we could use to start a discussion around the implementation (as opposed to the more common discussion on syntax) of generics?</p></pre>shovelpost: <pre><blockquote>
<p>Would this be a place we could use to start a discussion around the implementation (as opposed to the more common discussion on syntax) of generics?</p>
</blockquote>
<p>The Go team has said it many times before. They don't need solutions. They need problems.</p>
<p><a href="https://groups.google.com/d/msg/golang-nuts/ENKY8suiUbs/jvkTmi3ZCAAJ" rel="nofollow">Relevant discussion on golang-nuts.</a></p>
<p>Edit: Quote the 3rd question and make it clear that I am replying to that only.</p></pre>jlund3: <pre><p>Forgive me for asking an honest question or being curious about how Go actually works...let me try again in a way that won't trigger your needless combativeness.</p>
<p>I have this problem were I have to use type assertions with the empty interface and/or reflection whenever I need a data structure that isn't a map, slice or channel. For example, using the package "container/heap" from the standard library requires type assertions to be added every time I remove something from my heap. It would make my code much cleaner, more readable, and less brittle (and yes, I have accidentally screwed up before and had panics due to failed type assertions) if there were some mechanism to have static type checking on custom data structures like we get with maps, slices and channels. I don't have a solution to this problem, but it might be interesting to hear about how Go solves the problem for the built in data types.</p></pre>shovelpost: <pre><blockquote>
<p>Would this be a place we could use to start a discussion around the implementation (as opposed to the more common discussion on syntax) of generics?</p>
</blockquote>
<p>To clarify, I was replying to your 3rd question which I didn't quote and that created confusion. That's my bad.</p>
<blockquote>
<p>let me try again in a way that won't trigger your needless combativeness.</p>
</blockquote>
<p>I know it's hard to express tone with written speech so I understand your feelings.</p></pre>wavy_lines: <pre><p>Holding your fingers to your ears and screaming "lalalalala" does not make people's problems go away.</p>
<p>Pretending not to know what the problem is? Give me a break.</p></pre>kalekold: <pre><p>What a wonderful way to indefinitely park a feature request.</p></pre>faiface: <pre><p>They don't.</p>
<p>Serious answer: depends on what you mean. If you mean angle brackets from other languages, those are not in Go. But, you can do a lot of generic stuff with interfaces and reflection.</p></pre>JavaSuck: <pre><blockquote>
<p>If you mean angle brackets from other languages, those are not in Go.</p>
</blockquote>
<p>What about square brackets from Scala? ;)</p></pre>George3d6: <pre><p>Interfaces are closer to typecasting than they are to generics. </p>
<p>They don't provide compile time checking of type safety an inccur overhead to use and even more so to use safely by checking the type.</p>
<p>I know they may be enough for go, but don't misslead people by calling an expensive and unsafe *void generics (which are safe, zero overhead and result in code generation)</p></pre>faiface: <pre><p>As <a href="/u/shovelpost" rel="nofollow">u/shovelpost</a> said, I'm not talking about imitating generics with interface{}. I'm talking about a proper use of interfaces for dynamic dispatch, without using type-casting. This is completely type-safe. Furthermore, it can do things that static generics can't do.</p></pre>shovelpost: <pre><blockquote>
<p>I know they may be enough for go, but don't misslead people by calling an expensive and unsafe *void generics (which are safe, zero overhead and result in code generation)</p>
</blockquote>
<p>He is most likely talking about interfaces and not the empty interface{}. Interfaces are the generics of Go.</p></pre>breamoreboy: <pre><p>As a newcomer to Go who is still trying to wrap his head around the language I enjoyed reading <a href="https://appliedgo.net/generics/" rel="nofollow">Who needs generics? Use ... instead!</a>. I especially like the summary at the end giving the pros and cons of various approaches.</p></pre>slowratatoskr: <pre><p>lol you've been trolled. this dude is a fellow pcj</p></pre>neoasterisk: <pre><p>We know. Everyone can click and see this person's history. But I believe it doesn't really matter in a welcoming community.</p></pre>shovelpost: <pre><p><a href="https://golang.org/doc/effective_go.html#interfaces_and_types" rel="nofollow">Read this section.</a></p></pre>whizack: <pre><p>In the traditional sense of C++ Templates or C#/Java Generics, the concept doesn't exist in Go.</p>
<p>However, there are many cases where using interfaces can accomplish similar goals. The sort package is one example of a generic algorithm applied in this way. </p>
<p>That said, I would not call it a <em>good</em> example. The sort package is a very confused API that can't decide if it's a functional or interface driven design.</p></pre>govision: <pre><p>If you want the long answer</p>
<p><a href="https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/mobilebasic" rel="nofollow">https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/mobilebasic</a></p>
<p>Basically generics make complex things easier but at a cost because they are generic. Much like how the open interface has a cost of type checking. You are attempting a one size fits all answer. The go team wants a specific use case to maybe implement a feature with a not so one size fits all answer. </p>
<p>I still need to research use cases on why people embed interfaces in interfaces... Or maybe I should stay out of that lol. Eitherway, it's kinda like finding the perfect code for the reasons just described.</p></pre>
