Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Golang generics proposal has been accepted

github.com

Post reply on HN
Print view View original

41–50 of 176 posts

Re: Golang generics proposal has been accepted

#41

Post by baby »

cies wrote: post #14
cies wrote: post #5

This was to be expected. But I'm glad for Go. In some years a language that interops with Go comes out, where all the Go types have a ?-suffix indicating they are nullable. The language will be mostly null-safe. Also it will sport sumtypes and pattern matching/ destructuring in switch statements. It will be called: Gotlin.

Of course I'm joking, but I think implicit nullability is the worst part of Go. A language designed in a era when this was widely known as the billion dollar mistake (prolly even more expensive). But this is not easily reversed. Not as easy as tagging generics onto the language. And the parallels with Java's maturing are just lovely. Also, we have seen what Kotlin is now doing for Java: a new language was needed to t…

Golang needed sum types (for options) and match statements (python got it after all...) way before it needed generics. CHANGE MY VIEW.

Re: Golang generics proposal has been accepted

#42

Post by wwarner »

lastofus wrote: post #18

Out of curiosity, what changed between now, and when proposals for generics came up in years past?

The main difference between the accepted proposal and the original proposal is that the original proposal introduced contracts and the accepted proposal folds all that functionality into interfaces.

Re: Golang generics proposal has been accepted

#43

Post by baby »

gautamcgoel wrote: post #4

This will probably be downvoted, but I personally never felt a huge need for generics. C doesn't have them and is arguably the most successful language in history. Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. I suspect that this proposal being accepted is largely due to the huge growth of the Go community - I bet the original team (in particular, I'm thinking of Rob P…

Agree with you on the generics, they make code harder to read and the biggest selling point of Golang is that it's easy to audit/read/understand.

IMO Golang needed sum types and match statements, but it didn't need generics.

Re: Golang generics proposal has been accepted

#44

Post by piinbinary »

Cyph0n wrote: post #35
cies wrote: post #24

Earlier quoted context omitted.

Well, we know now, contrary to what was said about generic-and-Go when Go came out: Go can apparently not do without generics. What I always found hard to swallow is that Go's build in functions sometimes did have generics. Just you as a library/application writer were not allowed to create APIs with generics yourself.

Yep, seemed weird to me how (a form of) generics existed, but was exclusive to the stdlib/language. If generics were unnecessary, why did the stdlib/language need them? Couldn't they just have lived with, e.g., make_map, make_slice, make_chan, etc?

And a separate copy of `append` for every possible type :)

Re: Golang generics proposal has been accepted

#45

Post by cies »

Cyph0n wrote: post #35
cies wrote: post #24

Earlier quoted context omitted.

Well, we know now, contrary to what was said about generic-and-Go when Go came out: Go can apparently not do without generics. What I always found hard to swallow is that Go's build in functions sometimes did have generics. Just you as a library/application writer were not allowed to create APIs with generics yourself.

Yep, seemed weird to me how (a form of) generics existed, but was exclusive to the stdlib/language. If generics were unnecessary, why did the stdlib/language need them? Couldn't they just have lived with, e.g., make_map, make_slice, make_chan, etc?

Exactly. It was IMHO pretty authoritarian to say "you dont need generics" and then use it yourself in the standard lib.

But then Go is not a public place: it's private domain of Google.

I decided long time ago I dont want to learn a private tool without being paid.

Re: Golang generics proposal has been accepted

#46

Post by _y5hn »

CarelessExpert wrote: post #21
gautamcgoel wrote: post #15

Earlier quoted context omitted.

Haha, touche. Your response is fair. My point was only that some people act like any successful language must have generics, which is demonstrably false IMO. I am not opposed to innovation and ergonomics (hence, my support for arbitrary precision ints), but we should carefully weigh the pros and cons of every new proposal, especially if it increases the complexity of the language and toolchain. In my opinion, the ben…

First: I ninja-edited my comment after the fact with a thought that occurred to me after I posted, so apologies there. Anyway, yeah, no argument there at all. I'll be honest, as an outsider that's somewhat familiar with Pike's obsession with simplicity in Go, I'm actually a bit surprised this is getting in. It does seem like the kind of high-complexity feature that was deliberately excluded from the language as part…

Well, then you also know he just didn't see any good implementations of generics, yet. Let's hope this gets good!

Re: Golang generics proposal has been accepted

#47

Post by Cyph0n »

wahern wrote: post #13
opnitro wrote: post #8

Earlier quoted context omitted.

C may not have generic types, but much of the standard library does use generics, just through the unsafe mechanism of `void*`. Likewise, go already includes some generic code (the array type), it's just treated specially.

The equivalent to a void pointer in Go is interface{}. But very little of the C standard library uses void pointers--basically only those interfaces dealing with untyped blocks of memory, such as malloc and free. IME, you see interface{} far more often in Go code than you see void pointers in C code. And C actually has bone fide generics capabilities with _Generic, it's just very simple and manual.

void * is very useful as an opaque pointer type. For example, it's used all over the place in collection implementations and user-defined arguments (e.g., callbacks, pthread_create).

It might not be used much in the stdlib (which is relatively small!), but libraries and applications rely on void * heavily in my experience.

Re: Golang generics proposal has been accepted

#48

Post by f8o »

zwieback wrote: post #12
opnitro wrote: post #8

Earlier quoted context omitted.

C may not have generic types, but much of the standard library does use generics, just through the unsafe mechanism of `void*`. Likewise, go already includes some generic code (the array type), it's just treated specially.

For me the desire to use generics shows up once I've invested some time in making fancy types. When I work in C that point is never reached since problems are solved "the C way". Personally I'm a huge fan of generics but I can understand how the keepers of Go might be reluctant to go down the path of C++, Java and C#.

I think that C# has a successfull implementation because it isn't just about syntax sugar. The runtime knows it. Generics+structs allows many optimizations.

Re: Golang generics proposal has been accepted

#49

Post by hota_mazi »

SeanLuke wrote: post #16
maurys wrote: post #2

I wonder if over time, Golang will pick up more type features like Java and other languages have. The general consensus seems to be that powerful type systems are very effective. Personally, the low footprint runtime and concurrency primitives are enough for me and I wouldn't mind the language becoming "less simple" if it helps the ecosystem. Once generics are implemented, I can imagine people requesting for the next…

> I wonder if over time, Golang will pick up more type features like Java and other languages have. I hope it doesn't pick them up like Java did. When Java was considering generics, there were two major proposals out there. Sun decided on easily the worst one: type erasure. Now we're stuck with it. When Java was considering closures, there were two major proposals out there that I recall [one being to get rid of Java…

Type erasure was the best of these options, and it's one of the main reasons why Java became even more successful than it already was, and also the main reason why there are so many languages created on top of the JVM (as opposed to .net, which supports reified generics, which complicates enormously writing languages on it, especially for interop reasons).

More details: https://www.beust.com/weblog/erasure-vs-reification/

Re: Golang generics proposal has been accepted

#50

Post by baby »

hota_mazi wrote: post #38
gautamcgoel wrote: post #4

This will probably be downvoted, but I personally never felt a huge need for generics. C doesn't have them and is arguably the most successful language in history. Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. I suspect that this proposal being accepted is largely due to the huge growth of the Go community - I bet the original team (in particular, I'm thinking of Rob P…

PHP was also hugely successful, success is not the criterion by which this kind of feature should be decided. The bottom line is that generics allows the production of safer, more robust, more evolvable, more documented, more performant, code. Along with static typing, generics are simply a feature that no language created recently should be without.

and less readable, less auditable, less understandable, etc.
Post reply on HN