Proposal: Go should have generics

I work on juju (<a href="https:&#x2F;&#x2F;github.com&#x2F;juju&#x2F;juju" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;juju&#x2F;juju</a>), which all told is about 1M LOC. In my almost 3 years on the project, I have not been bothered by lack of generics, basically at all (and I worked for 10 years in C# on projects that used a lot of generics, so it&#x27;s not like I don&#x27;t know what I&#x27;m missing).<p>Do we have 67 implementations of sort.Interface? Sure. Is that, by any stretch of the imagination, a significantly difficult part of my job? No.<p>Juju is a distributed application that supports running across thousands of machines on all the major clouds, on OSes including CentOS, Ubuntu, Windows, and OSX, on architectures including amd64, x86, PPC64EL, s390x... and stores data in a replicated mongoDB and uses RPC over websockets to talk between machines.<p>The difficult problems are all either intrinsic to the solution space (e.g. supporting different storage back ends for each cloud), or problems we brought on ourselves (what do you mean the unit tests have to spin up a full mongodb instance?).<p>Generics would not make our codebase significantly better, more maintainable, or easier to understand.

I can feel the pain on the Sort issue. I&#x27;ve personally found sorting annoying in Go - I had a bunch of structs representing data entities from a database that all had the same field and I wanted to be able to sort them by this field.<p>Seemed like a LOT of work (basically implementing the same sort that was 99% identical for every struct) or use weird reflection-workarounds to get this to happen. In Java I would not even given this a second thought and be back to coding up the important part of the code ages ago.<p>I am a new go-lang user so would love to know what the best approach to resolve this is without a) repeating the same thing for every struct, or b) relying on &quot;unsafe&quot; reflect techniques (since AppEngine rejects code that does that) - surely sorting structs is a super-common, basic thing for a systems language? I&#x27;ve seen someone just nonchalantly say &quot;Use interfaces&quot; but I&#x27;m not sure still.<p>I like the language generally but this is a real &quot;WTF?&quot; moment for me.

After watching Rob Pike&#x27;s Go Proverbs talk I am pretty convinced generics, as much as some would want it, will never happen. He proselytizes &quot;just copy a little code here and there&quot; quite clearly, which is at odds with the complexity that generics would add.

Generics as a language retrofit tend to be ugly. See C++.<p>I was at one time plugging for parameterized types. Go already has parameterized types; &quot;map&quot; and &quot;chan&quot; are parameterized types. You write &quot;make(chan int)&quot; and &quot;make(map[string] int)&quot;. You just can&#x27;t define new parameterized types; &quot;map&quot; and &quot;chan&quot; are all you get. With parameterized types, you could create more generic data structures; if you needed a generic b-tree or a quadtree library, you could have one. Maps in Go are more special than they should be.<p>Parameterized types are less powerful than generics, but not too far from what Go now has. The goals in the document mentioned here require generics with all the bells and whistles. Remember, Go still has reflection; if you don&#x27;t need high performance, you can simulate generics at runtime.

&quot;The intent is not to add generics to Go at this time, but rather to show people what a complete proposal would look like. We hope this will be of help to anyone proposing similar language changes in the future.&quot;<p>This started in 2010. Hopefully an illustration that go&#x27;s developers are not against generics in general, this ought to quell some of the negativity... Pick one of the four proposals you like :)

What people think of generic package instead of fine grained generics? <a href="https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4&#x2F;edit#heading=h.wko1dvdznk4y" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;document&#x2F;d&#x2F;1vrAy9gMpMoS3uaVphB32uVXX...</a><p>I think they would really fit the language well. The good part is:<p>* Only the package and import statement change, the rest of your code stay the same and is not cluttered<p>* They are easier to reason about as it is more coarse grained<p>* They do not break the compatibility<p>The the bad part is:<p>* You cannot implement filter&#x2F;map&#x2F;reduce (but being able to implement them would conflict with the orthogonality of the language)<p>* It could lead to code bloat, but not more than manually copy pasting the code.

As long as programmers that are comfortable with (and prefer) 30+&#x2F;40+ year old PL paradigms are at the helm of Go&#x27;s design, it&#x27;s not very likely the language will grow Generics.<p>To paraphrase Max Plank:<p>&quot;A new language-level feature does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it.&quot;

My code is full of map, filter, reduce&#x2F;fold and similar generic reusable functions.<p>How do people deal with such things in Go? Do they really make copies of such functions for every type they&#x27;re working with? (And by type I don&#x27;t mean just int&#x2F;string, but all model entities&#x2F;classes.)

Lack of generics was one of the reasons I abandoned Go halfway through a hobby project (the other reason was lack of normal exceptions).<p>But. Go&#x27;s principle is simplicity and understanding the concepts you&#x27;re working with. And generics as a concept is a little bit more complex than simple List&lt;int&gt; explanation leads you believe. As C# developer (language with very good generics support), most of other C# developers I&#x27;ve met, unfortunately, can not easily and confidently explain covariance and contravariance concepts in an interview setting — which means that they don&#x27;t understand generics concept completely. Mix it up with &quot;null&quot; virtual type, and you&#x27;ve got yourself a type system that you think you understand, but really don&#x27;t, and will discover this misunderstanding in the worst possible moment.<p>So, while Go sucks for projects that I personally usually work on, its qualities make it a great language for other kinds of projects, and for these projects, generics may not be wort it with a trade off with simplicity.

Maybe instead of adding generics to Go it&#x27;s time to look into alternative programming languages which already implement generics, like for example Nim.

&quot;Let the machine do the work.&quot; [1]<p>By Rob Pike, a man of contradictions.<p>[1] <a href="https:&#x2F;&#x2F;blog.golang.org&#x2F;generate" rel="nofollow">https:&#x2F;&#x2F;blog.golang.org&#x2F;generate</a>

Consider using the D language instead if generics is a problem. Go is what it is and shouldn&#x27;t change. It has it&#x27;s advantages that make it optimal for particular contexts. Otherwise you&#x27;ll turn it into another c++. There is a strong benefit in keeping Go simple as it is.

I would be happy if there was a generics solution aimed just at type-safety for containers, and not a general &#x27;reuuse&#x27; thing.

Let me give a concrete example of how I&#x27;ve been personally impacted by the lack of generics. My project makes liberal use of pointers to represent &quot;optional&quot; fields, since they need to be distinguished from the zero-type. Alternatives would be to have a boolean associated with every field, but that clutters the API and still faces a lot of the problems with using pointrs, such as:<p>- Easy to forget to check that pointer != nil<p>- Overloaded semantics: it&#x27;s unclear whether a pointer represents an optional type, or is being used to pass-by-refrence (i.e. unclear whether a value should be treated read-only)<p>- Need to deep copy every struct, which is easy to forget and inefficient (at least the reflect version)<p>There are solutions to each of these points, but they all add complexity (e.g. generating code), and most take a lot of extra effort. With generics I could have Optional&lt;T&gt;, With a Get() function returning 2 values: the value type, and present (i.e. the way maps work). The caller is forced to handle both returns, making it much harder to forget to check it.<p>A lot of arguments for generics focus on higher-level functional programming abstractions, but this is a simple and extremely common use-case, and the lack of a solution is responsible for many real-world bugs.

There was a time when the only language with decent platform support <i>had</i> to have turing-complete meta-programming support, inheritance, polymorphism, lambdas, preprocessor, custom allocators, placement new, std::erase_if, etc, etc. because we were basically stuck with it.<p>Those times are now way behind us. Today, there is a plethora of languages to choose from, each with their strengths and weaknesses, each most powerful in the niche it&#x27;s designed for.<p>Go is not a language with generics. If you need generics, don&#x27;t use Go.<p>Go should not have generics unless it&#x27;s trying to dominate the world. And we all know that no language can achieve world domination nowadays, not anymore. So it should rather trying to be the best language possible in the niche it was designed for. That niche doesn&#x27;t need generics. On the contrary, a vocal part of the community says generics would taint Go.<p>Go doesn&#x27;t have generics. It&#x27;s however got a proper FFI. Use it. Or don&#x27;t.

Isn&#x27;t a huge issue with generics the compilation time?<p>Much as I love Haskell, I&#x27;m not going to sit here and tell you that a big program compiles quickly.<p>That might be an individual issue with Haskell, but regardless, isn&#x27;t type-inference kind of expensive in compilation-land? And wouldn&#x27;t that kind of kill one of the big features of Go?

At this point, I have to just conclude that Go isn&#x27;t &quot;for me&quot;. I respect the great things the community has produced. But I&#x27;m just not interested in a static language without generics.

As an outsider, I&#x27;ve been following Go for a while, and given the lack of common high productive language features such as Generics and optional function arguments with default values, to me, it seems like right now Go is much better than C, and in some dimensions better than Java and in others worse.<p>If it just adds a few things, and then when you account for portability and speed, it could be better than the dynamic languages that people often compare it to.

I have some biased doubts (come from the JVM world) about needing really fast compiling and is often cited as the reason Go does things the way it does (or is).<p>Is binary dependency management just not an option ever?<p>I have a friend that works for Google and supposedly they have a proprietary build infrastructure that will offload the building of C++ code into a cluster. I sort of wish Google open sourced that as I believe it basically does some form of binary dependency management.<p>Yes I know Go like C++ can target lots of platform (and thus needs many binaries built) but an organization only needs the major ones. And yes I know the language statically compiles to a single binary but that doesn&#x27;t mean things can&#x27;t be precompiled.<p>Go these days seems to be mainly used for microservices or small utilities and thus you don&#x27;t need and should not have a gigantic code base for such things. I can understand monolithic UI apps having large code bases but this is clearly not what Go is being used for these days.<p>There are many other languages that compile to native that seem to compile fairly fast (OCaml and Rust from my experience but I don&#x27;t have huge code bases).<p>Is compilation speed really an issue given the use cases for Go?

This makes me wonder if this has happened before in another language. I can totally imagine 10 years ago someone saying &quot;oh we&#x27;ll never need that in PHP&quot; and voila 10 years later you&#x27;ve now got feature X in PHP. Any of you wise old timers want to share such examples? Does history keep repeating itself with these sorts of things?

From the post:<p>&gt; As Russ pointed out, generics are a trade off between programmer time, compilation time, and execution time<p>This misses the most important metric: quality. Lack of generics forces copying and pasting of code which inevitably lowers quality and increases defects. It&#x27;s amazing to me that with the all the expense that crappy software causes, we&#x27;re more focused on compilation and execution time. Last time I checked Golang&#x27;s performance numbers, the supposed benefits of this focus were not present while the downsides of being a language that forces programmers to do the wrong thing were present as well.

Proposal: Algol should have dependent types.

The one thing that makes Go special is that it&#x27;s pure &quot;Engineering-Zen&quot;.<p>While that doesn&#x27;t make programming in Go the most <i>fun</i> exercise it makes it a profound one (after some getting used to).<p>Less distractions, less eGo (forgive the pun).<p>Disclaimer:<p>I&#x27;m still having a hard time embracing all of that myself - I don&#x27;t even <i>like</i> Go.<p>I <i>really</i> miss all the functional cleverness I&#x27;ve come to get used to over the years - especially talking Erlang&#x2F;OTP as the main (losing) &quot;competitor&quot; for most of my backend projects here (microservices, kubernetes yaddayadda).

Could anyone here tell me why, in practice, it isn&#x27;t possible to write generic algorithms such as sorting or Red&#x2F;Black T using interfaces only in GO ? It seems like having interfaces such as &quot;comparable, equatable,etc&quot; should work in theory.<p>I&#x27;ve read somewhere that it was memory usage related, but i&#x27;ve got trouble picturing why (maybe an example would help)

Can you give an example of the issue you&#x27;re trying to solve with Generics and Go is giving you hard time? don&#x27;t take Go to C++.

Go is supposed to be a better C, not a better C++.

Came for a Proposal. This article only provides <i>motivation</i> for generics.<p>Are there any concrete proposals on the table? I don&#x27;t recall seeing any, and it would be great to work from that and pick it apart. Otherwise, we&#x27;re just arguing the opinion that they&#x27;re useful, against the opinion that they&#x27;d soil the language.

If it was up to me I would break with ASCII for the syntax. It would make parsing easier for the compiler while simultaneously making it slightly annoying to use for the programmer.<p>Having to reach for a complex key combination would be enough to remind everyone that Generics should be used sparingly.

The four proposals linked at the bottom of the page are very interesting, and prove that a lot of work have already been invested in bringing generics to Go. It makes me confident that it will happen one day, when the pieces fit together in a nice way.

Sitting in a lecture by Kernighan rn and he says GO will NOT be implementing generics

can I tell u the BEST thing about golang? Strings cannot be nil! It&#x27;s amazing. They are always &quot;&quot; or you know, &quot;something&quot; so you never have to test for if s == nil || s == &quot;&quot; or in ruby s.blank? to cover both cases. that is all.

Rich Hickey could play on golang, this guy is so fascinated by simplicity too.

How does Erlang solve it?

If you google &quot;brutally practical&quot; you will get &quot;uninspired hack&quot;. Either that or the whole thing is simply pre-alpha

One day someone will create a fork and implement it.

just fork the repo.

Why not just fork the language? Why does one language need to do all the things?

If they accept generics, then there is an implication that the language design isn&#x27;t infallible as a result of being written by Rob Pike, and then the whole house of cards falls down as people start clamouring for things like real exceptions.

Go is designed by google, for google. Why should they make it to your liking? Why do you rely on google?

I agree with the author&#x27;s request, I&#x27;m just not convinced he proposes a design. I mean I recognize see the need for some sort of generic programming, but the big question is <i>how</i> not why, right?<p>Edit: My bad. Didn&#x27;t see the bottom of the page.