Idiomatic Generics in Go

If a language is not dynamically typed then it&#x27;s cumbersome not to have generics, that&#x27;s for sure.<p>On the other hand what I really like about go is that they are the only popular recent language that pushes back against a lot of modern features and says: &quot;It doesn&#x27;t matter how clever those features are, overall simplicity and consistency matters more.&quot;<p>The point is that we really need this experiment. It&#x27;s in everybody&#x27;s interest that the go people push back and continue to keep the language minimal. In a few years time someone will say on the internet that unless you have features x, y, and z in a language you simply cannot be productive&#x2F;concise&#x2F;maintainable&#x2F;performant&#x2F;safe&#x2F;not-a-blub. At that point it may be possible to point at some evidence and say &quot;Well I noticed that those machine learning guys at myAppsTheGreatest.com wrote a large system in go&quot;. Then you can go study it and see if they really needed those features. You can also ask the developers who used it and hopefully some of them will also have experience in [insert crystalline functional language here] so you can get them to weigh up the pros and cons. Go is an experiment that is needed.

I also miss generics in Go. It is especially a pain to implement a nice high performance collections library without them. I have been working on and off on a data-structures library and you have to go through a lot of hoops to make it nicely usable and your still end up with `interface{}` everywhere.[1]<p>It should be noted that this is not the first attempt by any means. droundy implemented basically this several years ago.[2] The problem is these things are non-standard and I don&#x27;t feel comfortable using them. I want generics but I want them as part of the language not as some weird third party CGI script. I also want them integrated into the template system. That way I can create type variables which must implement an interface. However, when the code is actually run, it isn&#x27;t an interface object it is the actual object. Features like that would make them fit much better with the rest of the language.<p>[1] <a href="https://github.com/timtadh/data-structures" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;timtadh&#x2F;data-structures</a> [2] <a href="https://github.com/droundy/gotgo" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;droundy&#x2F;gotgo</a>

It is worth pointing out that if the Go community settles on something like this as the solution, it negates one of the underlying arguments that the Go designers have against generics in the language. They have a set of criteria necessary for them before they are willing to put a solution in the language [1], and one of them is that they aren&#x27;t willing to do C++-style template-based generics that involve compiling separate functions for every generic instance, causing the binary to grow in size.<p>But all the other solutions that are headed into that gap are just one level or another of convenience wrapper around exactly that. If the Go community just starts doing this at scale, then there&#x27;s really no reason not to pull that up and make it official.<p>[1]: Whether or not you believe that they&#x27;re just against them full stop and can&#x27;t be budged no matter what, there&#x27;s at least some claimed reasons.

Go, which claims not to have either generics or objects, has both for built-in types. Channels and maps are both opaque objects and parameterized types. The argument that generics are unnecessary would be more convincing if those built-in types were not needed. The problem is adding generics without making a mess of things. This is harder than it looks.<p>In the example, there&#x27;s a set of &quot;int&quot;, and a set of &quot;string&quot;. A new set is created with<p>set := set.New()<p>in both cases. It looks like you could not instantiate &quot;set&quot; for both types in the same program without a name clash. That&#x27;s no good. Parameterized types for Go make sense, but the types need to be given a user defined name each time you create one. With &quot;generics as a service&quot;, you&#x27;d have to encode that name into the &quot;import&quot; statement, which is getting a bit clunky.<p>Go&#x27;s lack of generics is a reaction to the mess C++ made of them. In C++ the generics system turned into an entire compile time programming environment based on term rewriting rules. Nobody wants to go there again. But Go went too far.

Go seems to be re-inventing C++ and Java one step at a time.<p>Go didn&#x27;t learn from history, and is doomed to repeat it.

Whenever this issue comes up (and on HN, it never appears to die), I&#x27;m reminded of an eye-opening moment I had reading Rob Pike&#x27;s excellent essay &quot;Less is Exponentially More&quot; (<a href="http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html" rel="nofollow">http:&#x2F;&#x2F;commandcenter.blogspot.com&#x2F;2012&#x2F;06&#x2F;less-is-exponentia...</a>).<p>An excerpt (original emphasis): &quot;Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark...What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types...But more important, what it says is that <i>types</i> are the way to lift that burden. <i>Types</i>. Not polymorphic functions or language primitives or helpers of other kinds, but <i>types</i>.&quot;<p>It seems to me that people program heavily with types because that&#x27;s what compilers are really good at. Therefore that&#x27;s what most languages give us. But I don&#x27;t want to be constructing huge, complex type hierarchies with every application. If I&#x27;m spending more time on that than the actual problem domain, generic type systems are more of a problem than a solution. I don&#x27;t use a hammer because I love driving in nails, I use it because it&#x27;s the best way to stick two pieces of wood together.<p>(edit: perhaps I should clarify that I&#x27;m referring to type hierarchies within the application itself as an intrinsic part of design, not <i>language</i> type hierarchies)

If workarounds like these are common in the use of Go then leaving it out of the language was a mistake. The argument that generics comes at a complexity cost is nonsense: unless used it has no cost, the code would look like code does today. The complexity added by NOT having generics in a strictly typed language is enormous (as these examples show).

I honestly have mixed feelings about this. It is a really nice showcase of what the standard library can do (walking the AST and modifying it) with little amount of code.<p>OTOH it would be better to not make this a web-service. As much as it may seem to be convenient, integrating it with &quot;go generate&quot; (when it&#x27;s ready) would probably be easier to use and not pose any security risks ;)

What happens if you want two different types of set? As-imports? (I&#x27;ve looked at Go, but not written in it.)

being &quot;idiomatic&quot; is now the most important thing in Go, apparently.

How about my own types?

&quot;If you think it&#x27;s simple, then you have misunderstood the problem.&quot;<p>Bjarne Stroustrup

I found a better solution - abandoned the language.

Throwing type-safety out the window is so 2006. Just use Scala.

CGI...shell script...