
A concise guide to the latest Go generics draft design - pmihaylov
https://pmihaylov.com/go-generics-draft-design/
======
stickupkid
I feel the lack of additional type arguments on methods will be considered a
mistake in the longer term. Although the way it's designed it can be added in
additional revisions but considering it's taken rather a long time to get
here, I don't hold much hope for it landing for some time.

Attempting to define a generic Map function turns out to be somewhat
troublesome[1]. This would be really painless if you had type arguments,
instead, we have to define an interface to allow peeping into the type and
creating a type from a zero value.

Don't get me wrong, I do applaud the efforts for better type system, it's just
a weakness in the proposal.

1\.
[https://go2goplay.golang.org/p/P7CVwOW9wig](https://go2goplay.golang.org/p/P7CVwOW9wig)
(note this panics currently)

------
atombender
Good introduction.

I have to agree with other commenters that the syntax leaves something to be
desired. A lot of parentheses competing for attention.

Perhaps we could take a leaf from the Modula-3 book — Go was influenced by
Modula-2, which didn't have generics — and be more explicit in declarations. I
feel this would be more in the tradition of Go.

For example, instead of

    
    
      func Max(type T Comparable)(a, b T) T {
        if a > b {
          return a
        }
        return b
      }
    

This could instead be enveloped by a "generic" declaration like so:

    
    
      generic T Comparable
        func Max(a, b T) T {
          if a > b {
            return a
          }
          return b
        }

~~~
tandr
I will raise you with

    
    
      (type $T Comparable) func Max(a,b $T) $T {
          if a > b {
            return a
          }
          return b
        }

~~~
atombender
I like the idea of using special syntax to denote the type — $T signals that
it is a higher-order placeholder. It means there's no ambiguity to the reader
_or_ the compiler.

It also means that for a function that requires no type constraints, nothing
more is needed:

    
    
      func WorksWithAllTypes(val $T) {
        ...
      }
    

I don't like the type constraint syntax, though. I think it could be done like
this:

    
    
      func Max(a, b $T Comparable) $T {
        ...
      }
    

The idea here is that we only need to annotate the first instance of $T; all
others will implicitly share the same type constraint.

~~~
tandr
I posted semi-coherent thoughts on golang-nuts [1], but the message got
completely ignored

as for constrains, say if we use decorator, then since T has to adhere to one
interface only, func Max from your example could become

    
    
      func Max(a, b $Comparable) $Comparable {
      // ...
      }
    
    

[1] [https://groups.google.com/forum/#!topic/golang-
nuts/Rp3yUUy2...](https://groups.google.com/forum/#!topic/golang-
nuts/Rp3yUUy2nS8)

------
obilgic
Back in the day, if you mentioned generics on any Go post on HN, you would be
downvoted to the hell, interesting how everything comes full circle
(unfortunately a bit late).

~~~
jrockway
Go is on its way, like everything, through the Hype Cycle. It started at the
Peak of Inflated Expectations ("Java will disappear overnight, and I sure hate
Oracle and that one Java program I heard about 15 years ago"), and at that
stage, any article that mentioned Go would get upvoted. Then came the Trough
of Disillusionment. There were probably enough HN readers that had used it to
realize that it wasn't the solution to every problem -- bad Go written by bad
programmers was bad! I was promised that was impossible! It became the subject
of flamewars both from bad experience and to push back against the visibility
people didn't think it deserved. (Lots of reasons for this -- they wanted to
write something in Go and nobody let them, Go came from Google which HN hates,
etc.) The pushback here that really got traction was "Large company that I
would normally hate because they sell ads has rewritten some small Go
microservice in a new cool programming language." HN was willing to ignore its
hatred for large companies, ads, and microservices as long as the article was
shitting on Go. You gotta null out the Peak of Inflated Expectations somehow.
Now we have entered the Slope of Enlightenment. Go has most of what it needs
to be successful, and is objectively successful. So now it can be tweaked and
refined -- time spent in the trenches making TLS or HTTP/2 or GC better has
mostly made those things better, and it's on to the next things -- generics
being the big one.

You should watch the Hype Cycle very carefully with Rust. Rust is no doubt on
its way to a Plateau of Productivity, but right now we're at the point where
"My company only uses Rust!" or "I rewrote my foobarlang app in Rust!" will
get you to the first page... but "Wow, my CI system spent 387 CPU days
building my Hello World app last week!" is also starting to show up (on its
way to the Trough of Disillusionment).

I hate when things fall into rigid categories because it seems overly
simplistic, but the Hype Cycle is spot on. Look for it and you'll see it
everywhere.

~~~
networkimprov
Re "objectively successful" that's debatable. Looking at Google Trends, Go
mindshare is low & flat. [1]

I'm writing as a regular Go user who's found it very productive, tho I'm
worried about its future

[1]
[https://trends.google.com/trends/explore?date=today%205-y&q=...](https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F07sbkfb,%2Fm%2F05z1_,%2Fm%2F07657k,%2Fm%2F0bbxf89,%2Fm%2F09gbxjr)

~~~
jrockway
I am not sure what to make of search trends. I compared Go with Objective C
and Swift, and they are both lower than Go. That seems to mean that people are
writing more Go programs than iPhone apps, and there sure are a lot of apps
around these days. I am guessing there are a lot of confounding factors that
lead to search volume -- go users are going to "go doc foobar", which Google
does not track. Java puts the name of the programming language in nearly every
error message, which people often type into Google. While these do not affect
the trends (Java declining, Python increasing), they probably make it
difficult to compare the raw magnitudes between languages.

~~~
networkimprov
The slope of the lines is more telling than their relative levels.

------
sszz
Thanks for this—easier to digest than other posts I’ve seen. The ability to
restrict interfaces to specific types is pretty cool (unique?) but otherwise
seems like generics as usual, but with a distinct Go flavor. Looking forward
to using this and cleaning up some boilerplate!

~~~
maybeOneDay
Unless I'm missing something I can't see any constraining ability that isn't
possible in C#[0], for example?

[0] [https://docs.microsoft.com/en-
us/dotnet/csharp/programming-g...](https://docs.microsoft.com/en-
us/dotnet/csharp/programming-guide/generics/constraints-on-type-parameters)

~~~
scns
Maybe you are missing that this is not possible in Go yet?

~~~
throwaway894345
I do wish people would resist the reflex to overtly digress onto their own
favorite programming language in any given programming HN thread. I'm not
talking about insightfully comparing two languages; I'm talking about going
completely off-topic because you want to talk about your own favorite
language.

~~~
maybeOneDay
If this is in reference to my bringing up of C# - I did so in order to talk
about whether or not Go has generic constraints which are unique (which would
be awesome!). I used C# as an example of a language that has constraints that
are the same as/as powerful as those in this Go proposal so as not to be
making an unsubstantiated claim.

------
maxmcd
What kind of new libraries are we going to get with this change? Seems like
we'll see a proliferation of new data structure libs now that they can be
constructed without interface{}. What else?

~~~
jerf
Libraries that assemble channel structures, and libraries that may not provide
that functionality but depend on it internally, i.e., libraries that can set
up entire structures of goroutines that use channels under the hood. (Probably
another burst of "worker pool" libraries will pop up before once again the
community points out that native Go essentially provides worker pools with a
natural use of existing constructions already.)

While this is a subset of "new data structures", I'm really looking forward to
generic immutable structures that can be read by many goroutines but have some
coherent update story. I've got several places in my code where I have a
structure I want to update infrequently and have read access in a lot of
places, where I'm reading it enough that a traditional read/write lock is a
real problem. I've got some stuff hacked together but what I have can't be
shared as a library, and I shouldn't anyhow, because a real library ought to
be stronger and better.

(I recognize that Go doesn't have immutable data types, but I was programming
in Python for many years before Go and have made my peace with "Just don't do
that.")

Libraries that operate on maps and slices in a type-agnostic manner.

Probably some numeric libraries with nicer types than you can get now, though
I still think Go will be a bad choice for highly numeric code even post-
generics.

Several hundred map/filter/reduce libraries that nobody will use for very
long.

Data structures are the one I'm really looking forward to, though. Network
servers, nominally Go's wheelhouse, is one of those places that we tend to
like some obscure data structure choices because of the performance needs. It
has been a frustrating hole in the language for a while.

~~~
maxmcd
Thanks, this was super informative

------
tarkin2
I’m ignorant to golang’s generics saga, but I’m painfully familiar with Java’s
(to the point where I wasn’t overly sad when golang didn’t have them). Can
anyone explain what golang is doing better?

~~~
cle
Go is designing generics around the language tenets, which are quite different
from Java's. In themselves, generics aren't particularly interesting...it gets
interesting when you start considering the tradeoffs you need to make in order
to align them with the tenets of your language, runtime, and ecosystem. I
wouldn't say Go is doing generics "better", they are doing them "differently"
to align with the goals of the language.

(Personally, I'm not looking forward to generics in Go, I enjoy the simplicity
of not having them and haven't encountered situations where they'd make a huge
difference.)

------
YoyoyoPCP
Wish comparable supported all of the compare operators. Otherwise, this looks
like a nice design by the Go team!

------
cutler
Simplicity goes out the window. Oh well it was nice while it lasted.

~~~
gmassman
Looks a lot simpler than contracts... I'm much happier with the aesthetics of
using interfaces for generic constraints. Looks a lot simpler to use. Besides,
it's completely compatible with existing code, only a minor update will be
required. Seems to me to be one of those features people will ignore if they
don't want but love in the instances where there would otherwise be lots of
boilerplate and/or generated code.

~~~
throwaway894345
I didn't pay much attention to the contracts proposal; is this just simpler
because dynamic dispatch is vaguely similar to static dispatch, so it uses one
syntax construct (interfaces) to denote both? I'm not opposed to this, but
these aren't "interfaces" even though they use a similar syntax, notably the
"constraining to a set of types" is supported for constraints and not
interfaces.

The thing I worry about the most is that Go without generics works very well
for 95-99% of code. The code is very clear and not overly abstract. The
remaining 1-5% of code is hard to write in an efficient, type safe, and DRY
way, but I don't see how we can have generics and clear, appropriately-
abstract code. I strongly suspect this will change the quality of the
ecosystem for the worse. I don't think people consider this tradeoff very
often.

~~~
jasonwatkinspdx
> I don't think people consider this tradeoff very often.

Every single time generics in go is discussed, a sizeable fraction of the
comments are FUD about go inevitably turning into Boost. People consider the
tradeoffs often, but in a superficial and dogmatic way based on language
tribalism rather than actually looking at the proposal in detail and actually
considering the tradeoffs.

~~~
throwaway894345
You've misunderstood the debate. The concern isn't about Go turning into
Boost; it's about Go becoming multiparadigm--about losing the property that
"all Go code tends to be written in the same general way" and that people will
invariably write code that optimizes for abstraction instead of readability
and utility as invariably happens in other languages. If you're not used to
Go, you'll probably write this off very quickly because you underestimate (as
we all did before we tried Go) how nice it is to have standard, appropriately-
abstract code. This is why the debate inside the Go community is more nuanced
and amicable--people understand the tradeoff better; they're not shouting
uninformed opinions nor pretending there is no tradeoff or that the tradeoff
is "just FUD" based on their utter inexperience.

~~~
jasonwatkinspdx
This comes across as very patronizing. I've been using go for a couple years
now. I'm _very_ familiar with the detailed history of generics proposals in
go. I disagree with your characterization and perspective, and continue to see
it as simple FUD.

~~~
throwaway894345
If you were very familiar with the history, you would be well aware that
virtually no one is expressing a concern about generics turning Go into Boost.
That's a straw man of your own creation. You're welcome to see my
characterization and perspective however you like.

------
dalu
it doesn't matter what we say, Go is owned by Google and what they decide is
the Alpha&Omega, everything else will be silenced, banned, ridiculed, ignored,
closed, deleted. And in my case, my Adsense sites suddenly having "policy
violations" after 14 years of existence and pages being removed or deranked
from the Google index. Be careful what you say because those powertripping
ivory tower elitists will destroy your business if you have any earnings from
a partnership with one of their products. I'm willing to be if I had GCE
containers they would also have magical errors appearing just in the moment
when I DARED suggest they revert a font and they change their "brand" because
it's soulless and has nothing to do anymore with the spirit that made Go
popular, simplicity and readable code. Oh and of course one corrupt
organization washes the other's hands. Your github account will get flagged
without notice or reason given and inquiries will remain unanswered by Github.
Corrupt bastards is what the Go developers are.

Go is not _your_ (as in mine, ours) language. It's a language owned by a
corporation that turned evil, that spies on all of us and hands out data to
governments. An evil corporation that cooperates with totalitarian regimes,
because their mindset is similar anyway, so what's the deal, right? All just
business as usual. Screw the public, we own the place. .|.. Google and the Go
developers

