Toward Go 2

<p><pre><code> &gt; I can&#x27;t answer a design question like whether to support &gt; generic methods, which is to say methods that are &gt; parameterized separately from the receiver. </code></pre> I work on the Dart language. Dart was initially designed with generic classes but not generic methods. Even at the time, some people on the team felt Dart should have had both.<p>We proceeded that way for several years. It was annoying, but tolerable because of Dart&#x27;s optional type system -- you can sneak around the type checker really easily anyway, so in most cases you can just use &quot;dynamic&quot; instead of a generic method and get your code to run. Of course, it won&#x27;t be type safe, but it will at least mostly do what you want.<p>When we later moved to a sound static type system, generic methods were a key part of that. Even though end users don&#x27;t define their own generic methods very often, they use them <i>all</i> the time. Critical common core library methods like Iterable.map() are generic methods and need to be in order to be safely, precisely typed.<p>This is partially because functional-styled code is fairly idiomatic on Dart. You see lots of higher-order methods for things like manipulating sequences. Go has lambdas, but stylistically tends to be more imperative, so I&#x27;m not sure if they&#x27;ll feel the same pressure.<p>I do think if you add generic types without generic methods, you will run into their lack. Methods are how you abstract over and reuse behavior. If you have generic methods without generic classes, you lose the ability to abstract over operations that happen to use generic classes.<p>A simple example is a constructor function. If you define a generic class that needs some kind of initialization (discouraged in Go, but it still happens), you really need that constructor to be generic too.

I should send this to rsc, but it&#x27;s fairly easy to find examples where the lack of generics caused an opportunity cost.<p>(1) I started porting our high-performance, concurrent cuckoo hashing code to Go about 4 years ago. I quit. You can probably guess why from the comments at the top of the file about boxing things with interface{}. It just got slow and gross, to the point where libcuckoo-go was slower and more bloated than the integrated map type, just because of all the boxing: <a href="https:&#x2F;&#x2F;github.com&#x2F;efficient&#x2F;go-cuckoo&#x2F;blob&#x2F;master&#x2F;cuckoo.go" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;efficient&#x2F;go-cuckoo&#x2F;blob&#x2F;master&#x2F;cuckoo.go</a><p>(my research group created libcuckoo.)<p>Go 1.9 offers a native concurrent map type, four years after we looked at getting libcuckoo on go -- because fundamental containers like this really benefit from being type-safe and fast.<p>(2) I chose to very tightly restrict the initial set of operations we initially accepted into the TensorFlow Go API because there was no non-gross way that I could see to manipulate Tensor types without adding the syntactic equivalent of the bigint library, where everything was Tensor.This(a, b), and Tensor.That(z, q). <a href="https:&#x2F;&#x2F;github.com&#x2F;tensorflow&#x2F;tensorflow&#x2F;pull&#x2F;1237" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tensorflow&#x2F;tensorflow&#x2F;pull&#x2F;1237</a> and <a href="https:&#x2F;&#x2F;github.com&#x2F;tensorflow&#x2F;tensorflow&#x2F;pull&#x2F;1771" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tensorflow&#x2F;tensorflow&#x2F;pull&#x2F;1771</a><p>I love go, but the lack of generics simply causes me to look elsewhere for certain large classes of development and research. We need them.

The paragraph I was looking for is this:<p>&gt; For example, I&#x27;ve been examining generics recently, but I don&#x27;t have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can&#x27;t answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use cases, we could begin to answer a question like this by examining the significant ones.<p>This is a much more nuanced position than the Go team has expressed in the past, which amounted to &quot;fuck generics,&quot; but it puts the onus on the community to come up with a set of scenarios where generics could solve significant issues. I wonder if Go&#x27;s historical antipathy towards this feature has driven away most of the people who would want it, or if there is still enough latent desire for generics that serious Go users will be able to produce the necessary mountain of real-world use cases to get something going here.

Java`s generics have had issues due to use site variance, plus the language isn&#x27;t expressive enough, leading its users into a corner where they start wishing for reified generics (although arguably it&#x27;s a case of missing the forest from the trees).<p>But even so, even with all the shortcomings, once Java 5 was released people migrated to usage of generics, even if generics in Java are totally optional by design.<p>My guess to why that happens is that the extra type safety and expressivity is definitely worth it in a language and without generics that type system ends up staying in your way. I personally can tolerate many things, but not a language without generics.<p>You might as well use a dynamic language. Not Python of course, but something like Erlang would definitely fit the bill for Google&#x27;s notion of &quot;systems programming&quot;.<p>The Go designers are right to not want to introduce generics though, because if you don&#x27;t plan for generics from the get go, you inevitably end up with a broken implementation due to backwards compatibility concerns, just like Java before it.<p>But just like Java before it, Go will have half-assed generics. It&#x27;s inevitable.<p>Personally I&#x27;m sad because Google had an opportunity to introduce a better language, given their marketing muscle. New mainstream languages are in fact a rare event. They had an opportunity here to really improve the status quo. And we got Go, yay!

I get that everyone would love to have a functional language that&#x27;s eager by default with optional lazy constructs, great polymorphism, statically typed with inference, generics, great concurrency story, an efficient GC, that compiles quickly to self contained binaries with simple and effective tooling which takes only seconds to setup while giving you perfomance that equals java and can rival C, with a low memory footprint.<p>But, I don&#x27;t know of one, and maybe that&#x27;s because the Go team is right, some tradeoffs need to be made, and they did, and so Go is what it is. You can&#x27;t add all the other great features you want and eat the Go cake too.<p>Disclaimer: I&#x27;m no language design expert. Just thinking this from the fact that I&#x27;ve yet to hear of such a language.

<p><pre><code> &gt; To minimize disruption, each change will require &gt; careful thought, planning, and tooling, which in &gt; turn limits the number of changes we can make. &gt; Maybe we can do two or three, certainly not more than five. &gt; ... I&#x27;m focusing today on possible major changes, &gt; such as additional support for error handling, or &gt; introducing immutable or read-only values, or adding &gt; some form of generics, or other important topics &gt; not yet suggested. We can do only a few of those &gt; major changes. We will have to choose carefully. </code></pre> This makes very little sense to me. If you _finally_ have the opportunity to break backwards-compatibility, just do it. Especially if, as he mentions earlier, they want to build tools to ease the transition from 1 to 2.<p><pre><code> &gt; Once all the backwards-compatible work is done, &gt; say in Go 1.20, then we can make the backwards- &gt; incompatible changes in Go 2.0. If there turn out &gt; to be no backwards-incompatible changes, maybe we &gt; just declare that Go 1.20 is Go 2.0. Either way, &gt; at that point we will transition from working on &gt; the Go 1.X release sequence to working on the &gt; Go 2.X sequence, perhaps with an extended support &gt; window for the final Go 1.X release. </code></pre> If there aren&#x27;t any backwards-incompatible changes, why call it Go 2? Why confuse anyone?<p>---<p>Additionally, I&#x27;m of the opinion that more projects should adopt faster release cycles. The Linux kernel has a new release roughly every ~7-8 weeks. GitLab releases monthly. This allows a tight, quick iterate-and-feedback loop.<p>Set a timetable, and cut a release with whatever is ready at the time. If there are concerns of stability, you could do separate LTS releases. Two releases per year is far too short, I feel. Besides, isn&#x27;t the whole idea of Go to <i>go fast</i>?

Here be Opinions:<p>I hate generics. also, I hate exceptions.<p>Too many people are wanting &quot;magic&quot; in their software. All some people want is to write the &quot;Happy Path&quot; through their code to get some Glory.<p>If it&#x27;s your pet project to control your toilet with tweets then that&#x27;s fine. But if it&#x27;s for a program that will run 24&#x2F;7 without human intervention then the code had better be plain, filled with the Unhappy Paths and boring.<p>Better one hour writing &quot;if err&quot; than two hours looking at logs at ohshit.30am.

&gt; For example, I&#x27;ve been examining generics recently, but I don&#x27;t have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve.<p>This is sampling bias at work. The people who need generics have long since given up on Go and no longer even bother participating in Go-related discussions, because they&#x27;ve believe it will never happen. Meanwhile, if you&#x27;re still using Go, you must have use cases where the lack of generics is not a problem and the existing language features are good enough. Sampling Go users to try and find compelling use cases for adding generics is not going to yield any useful data almost by definition.

&gt; <i>For example, I&#x27;ve been examining generics recently, but I don&#x27;t have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. […] If we had a large set of real-world use cases, we could begin to answer a question like this by examining the significant ones.</i><p>Not implementing generics, <i>then</i> suggesting that it would be nice to have examples of generics being used in the wild… You had it coming, obviously.<p>Now what&#x27;s the next step, refusing to implement generics because nobody uses it?<p>&gt; <i>Every major potential change to Go should be motivated by one or more experience reports documenting how people use Go today and why that&#x27;s not working well enough.</i><p>My goodness, it looks like that <i>is</i> the next step. Go users have put up with the absence of generics, so they&#x27;re not likely to complain too loudly at this point (besides, I hear the empty interface escape hatch, while not very safe, does work). More exacting developers have probably dismissed Go from the outset, so the won&#x27;t be able to provide those experience reports.

Go doesn&#x27;t have const structs, maps or other objects:<p><a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;43368604&#x2F;constant-struct-in-go" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;43368604&#x2F;constant-struct...</a><p><a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;18342195&#x2F;how-to-declare-constant-map-in-golang" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;18342195&#x2F;how-to-declare-...</a><p>This is a remarkable oversight which makes it impossible to write purely-functional code with Go. We also see this same problem in most other imperative languages, with organizations going to great lengths to emulate const data:<p><a href="https:&#x2F;&#x2F;facebook.github.io&#x2F;immutable-js&#x2F;" rel="nofollow">https:&#x2F;&#x2F;facebook.github.io&#x2F;immutable-js&#x2F;</a><p>Const-ness in the spirit of languages like Clojure would seem to be a relatively straightforward feature to add, so I don&#x27;t really understand the philosophy of leaving it out. Hopefully someone here knows and can enlighten us!

There are many comments griping about generics. There are many comments griping about the Go team daring to even <i>ask</i> what problems the lack of generics cause.<p>But take a look at this article about the design goals of Go: <a href="https:&#x2F;&#x2F;talks.golang.org&#x2F;2012&#x2F;splash.article" rel="nofollow">https:&#x2F;&#x2F;talks.golang.org&#x2F;2012&#x2F;splash.article</a> Look especially at section 4, &quot;Pain Points&quot;. <i>That</i> is what Go is trying to solve. So what the Go team is asking for, I suspect, is concrete ways that the lack of generics hinders Go from solving <i>those</i> problems.<p>You say those aren&#x27;t <i>your</i> problems? That&#x27;s fine. You&#x27;re free to use Go for your problems, but you aren&#x27;t their target audience. Feel free to use another language that is more to your liking.<p>Note well: I&#x27;m not on the Go team, and I don&#x27;t speak for them. This is my impression of what&#x27;s going on - that there&#x27;s a disconnect in what they&#x27;re asking for and what the comments here are supplying.<p>(And by the way, for those here who say - or imply - that the Go team is ignorant of other languages and techniques, note in section 7 the casual way they say &quot;oh, yeah, this technique has been used since the 1970s, Modula 2 and Ada used it, so don&#x27;t think we&#x27;re so brilliant to have come up with this one&quot;. These people know their stuff, they know their history, they know more languages than you think they do. They probably know more languages than you do - even pjmlp. Stop assuming they&#x27;re ignorant of how generics are done in other languages. Seriously. Just stop it.)

As much as I want them to fix the big things like lack of generics, I hope they fix some of the little things that the compiler doesn&#x27;t catch but could&#x2F;should. One that comes to mind is how easy it is to accidentally write:<p><pre><code> for foo := range(bar) </code></pre> Instead of:<p><pre><code> for _, foo := range(bar) </code></pre> When you just want to iterate over the contents of a slice and don&#x27;t care about the indices. Failing to unpack both the index and the value should be a compile error.

The beauty of Go is that you get developer productivity pretty close to Ruby&#x2F;Python levels with performance that is similar to Java&#x2F;C++<p>Improvements to package management is probably the highest item on my wishlist for Go 2.

Generics have never stopped me from building in Go... But without them I often do my prototyping in python, javascript, or php.<p>Working with batch processing I&#x27;m often changing my maps to lists or hashes multiple times during discovery. Go makes me rewrite all my code each time I change the variable type.

How about fixing all the GOPATH crap?

As a ruby and go dev, I&#x27;m a bit sad to see backward-compatibility going. Thinking I could write code with minimum dependencies and that would just work as is years later was really refreshing compared to the high level of maintenance needed in a ruby app.<p>But well, I trust the core team to make the best choices.

I like Go concept: very simple and minimalistic language, yet usable enough for many projects, even at cost of some repetition. Generics are not a concern for me. But error handling is the thing I don&#x27;t like at all. I think that exceptions are best construct for error handling: they are not invasive and if you didn&#x27;t handle error, it won&#x27;t die silently, you have to be explicit about that. In my programs there&#x27;s very little error handling, usually some generic handling at layer boundaries (unhandled exception leads to transaction rollback; unhandled exception returns as HTTP 500, etc) and very few cases when I want to handle it differently. And this produces correct and reliable program with very little effort. Now with Go I must handle every error. If I&#x27;m lazy, I&#x27;m handling it with `if err != nil { return err; }`, but this style doesn&#x27;t preserve stack trace and it might be hard to understand what&#x27;s going on. If I want to wrap original error, standard library don&#x27;t even have this pattern, I have to roll my own wrapper or use 3-rd library for such a core concept.<p>What I&#x27;d like is some kind of automatic error propagation, so any unhandled error will return from function wrapped with some special class with enough information to find out what happened.

&gt; For example, I&#x27;ve been examining generics recently, but I don&#x27;t have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve.<p>Collections?

But I always heard never to use Go 2! :P

&quot;We estimate that there are at least half a million Go developers worldwide, which means there are millions of Go source files and at least a billion of lines of Go code&quot;

I must say that whenever there is a discussion about the merits of the Go programming language, it really feels hostile in the discussion thread. It seems that people are seriously angry that others even consider using the language. It is sort of painful reading through the responses which implicitly declare that anybody who enjoys programming with Go is clueless.<p>It also really makes me wonder if I am living in some sort of alternate reality. I am a professional programmer working at a large company and I am pretty sure that 95% of my colleagues (myself included, as difficult as it is for me to admit) have no idea what a reified generic is. I have run into some problems where being able to define custom generic containers would be nice, but I don&#x27;t feel like that has seriously hindered my ability to deliver safe, functional, and maintainable software.<p>What I appreciate most about Go is that I am sure that I can look at 99% of the Go code written in the world and I can understand it immediately. When maintaining large code bases with many developers of differing skill levels, this advantage can&#x27;t be understated. That is the reason there are so many successful new programs popping up in Go with large open-source communities. It is because Go is accessible and friendly to people of varying skill levels, unlike most of the opinions expressed in this thread.

Sorry, but if &quot;a major cloud platform suffers a production outage at midnight&quot; is the bar for effecting change in Go, then I want no part of it.

&quot;Go 2 considered harmful&quot; - Edsger Dijkstra, 1968

This is a frustratingly common way to design mainstream PLs: &quot;show me the use case&quot;. I&#x27;ve seen it firsthand for a number of big PL projects. People are trapped in their little bubble. My approach is to be wildly polyglot, actively searching for good ideas in other languages. Also, I try to write complex code outside the intended domain space and understand why it&#x27;s harder than it should be.<p>For example, in Go it&#x27;s difficult to implement state machines in a clean way. Another is handling events and timeouts is easier with Reactive programming. Distributed programming is easier with Erlang or Akka. Don&#x27;t wait for problem reports in the Go community. Look at the problems in other PLs and proactively improve Go.

I would love to see uniform-function-call-syntax.<p>Turning: func (f Foo) name() string<p>Into: func name(f Foo) string<p>Callable like this: f.name() or name(f)<p>Extending foreign structs from another package should be possible too, just without access to private fields.<p>Other than that, if-as-expression would be nice to have, too.

The leap second problem reminds me of this post[0].<p>[0] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14121780" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=14121780</a>

Disclaimer: I mean this with love<p>This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure BS. Go read the years worth of tickets asking for monotonic time, and see how notable names in the core team responded. Pick any particular issue people commonly have with golang, and you&#x27;ll likely find a ticket with the same pattern: overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue. It&#x27;s infuriating that the same people making those comments are now taking credit for the solution, when they had to be dragged into even admitting the issue was legitimate.

Regarding the lacking of generics problem, is there a way to get around it, there are always plenty of tools doing that, if the IDE can patch the syntax and support certain kind of prigma to generate the template code, then the problem is almost solved, not sure if it&#x27;ll cover all cases like Java does though.

This was announced at GopherCon today. FYI, if folks are interested in following along other conference proceedings, there is no livestream, but there is an official liveblog: <a href="https:&#x2F;&#x2F;sourcegraph.com&#x2F;gophercon" rel="nofollow">https:&#x2F;&#x2F;sourcegraph.com&#x2F;gophercon</a>

&quot;Play it cool&quot; <a href="https:&#x2F;&#x2F;youtu.be&#x2F;BHIo6qwJarI" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;BHIo6qwJarI</a> Go! by Public Service Broadcasting.<p>(Sorry just discovered this song a few days ago)

about generics : i&#x27;ve never had a deep look at it but i&#x27;ve always wondered if most of the problem couldn&#x27;t be solved by having base types ( int, string, date, float, ..) implements fundamental interfaces (sortable, hashable, etc). i suppose that if the solution were that simple people would&#x27;ve already thought about it.<p>in particular, i think it could help with the method dispatch, but probably not with the memory allocation ( although go already uses interfaces pretty extensively).

Most of the discussion here seems to be around generics, and it sounds like they still don&#x27;t see the benefit of generics.<p>I like Go, but the maintainers have a maddeningly stubborn attitude towards generics and package managers and won&#x27;t ease up even with many voices asking for these features.

&gt; <i>We did what we always do when there&#x27;s a problem without a clear solution: we waited. Waiting gives us more time to add experience and understanding of the problem and also more time to find a good solution. In this case, waiting added to our understanding of the significance of the problem, in the form of a thankfully minor outage at Cloudflare. Their Go code timed DNS requests during the end-of-2016 leap second as taking around negative 990 milliseconds, which caused simultaneous panics across their servers, breaking 0.2% of DNS queries at peak.</i><p>This is absurd. Waiting to fix a known language design issue until a production outage of a major customer is a <i>failure</i> of process, not an <i>achievement</i>. The fact that the post presents this as a positive aspect of Go&#x27;s development process is beyond comprehension to me.

I didn&#x27;t expect to get namechecked in that.<p>Shows the value of constantly being transparent and supporting open source projects.

Forget generics. What I missed most are algebraic data structures.

I was newly married and my husband and I intended on getting a house but our credit scores were low and I also had a few bank debts. I spoke to a friend about it who happens to be a tech guy and he introduced me to a hacker (blackbutcher). I contacted blackbutcher and he helped my husband and I boost our credit scores and he also helped me clear my bank debts. This hacker is a genius and comes highly recommended by a lot of people. He&#x27;s affordable and genuine unlike a lot of fakes I saw on the internet. Contact him on his mail blackbutcher.hacker@outlook.com

My main wish:<p>Please don&#x27;t <i>refuse</i> to compile just because there are unused imports.<p>Please do warn, and loudly say it&#x27;s NON-CONFORMANT or whatever will embarass me enough from sharing my piece of Go code with someone else.. but.. can I please just run my code, in private, when experimenting?

Will there be <i>gotos</i> in Go 2? Asking for a friend.

I suspect the authors of Golang got drunk, and challenged each other to see how many times they could get people to type &#x27;if err != nil&#x27; in the next decade.

I know there is a lot of discussion about generics, but I am not sure if that is missing the point. I mean &#x27;generics&#x27; sounds like a complex concept from the java development and I am uncertain if that&#x27;s really what we need in go.<p>From my experience I think we should talk about container formats because they make 80% of what we would like to have generics for. Actually, go feels as if it has only two container data structures: Slices and Maps. And both feel as if they are pretty hard coded into the language.<p>Yes, I am sure there are more container formats and it is possible to build your own, but I think it is not easy enough.