Live data from Hacker News

Golang generics proposal has been accepted

github.com

21–30 of 176 posts

Re: Golang generics proposal has been accepted

#21

Earlier quoted context omitted.

> C doesn't have them and is arguably the most successful language in history. I'm not sure "C didn't have it" is a good litmus test for determining the value of features... C is called a portable assembler for a reason. > Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. Conversely, proponents of generics would argue that not having them creates complexity for software de…

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 of its overall design ethos.

But it really comes down to a weighing of pros and cons. Generics have the potential (though definitely not the guarantee!) to trade off developer complexity for compiler and toolchain complexity, and the preference on that choice is a personal one.

Re: Golang generics proposal has been accepted

#22
post #13
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.

go's empty interfaces reminded me too much of the bad old days when everyone passed around Objects to java methods. I hated it.

Re: Golang generics proposal has been accepted

#23

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…

"I meant there are no plans for generics. That's not the same as saying we plan not to do generics. It just means we don't have a plan.

The FAQ is still accurate.

-rob"

"The time has come to change Go, given what we have learned over the past decade of using it in production. -rob"

the reason this proposal was accepted is because rob and others liked this plan and said over a decade of production taught them it is an important thing to have, in fact rob asked wadler and company to help get things right for go.. so i would say you'd bet wrong

Re: Golang generics proposal has been accepted

#24

Earlier quoted context omitted.

> C doesn't have them and is arguably the most successful language in history. I'm not sure "C didn't have it" is a good litmus test for determining the value of features... C is called a portable assembler for a reason. > Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. Conversely, proponents of generics would argue that not having them creates complexity for software de…

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…

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.

Re: Golang generics proposal has been accepted

#25
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 think I'm ok with this as well.

The developers behind Go have a really strong culture of taking a ton of time to implement any major language changes; very reminiscent of Java and C++. Talk around Generics began, well, when the language was first created, but even more seriously like five years ago, and it'll probably be another year before it hits production.

I love this. Language changes need to be thought through considerably, with all angles considered, and by going slow it gives major developers time to give feedback, prepare, and most critically not always feel like the code they write will go out of date in three months. By comparison, writing anything in, say, Rust (and JavaScript ~four years ago, its better nowadays) feels exhausting, because its a constant battle with changing culture and evolving best practices.

My favorite feature of Go is its characteristic of not carbon-dating codebases. Go written a decade ago looks almost the same as Go written today; Contexts would be the single major pseudo-language-level feature added in that interim which may give away newer code. Adding new features is still important, balance in all things etc, and code written after generics will give another epoch of carbon dating. Go strikes this balance in a way that should be a model for every other language.

Re: Golang generics proposal has been accepted

#26
post #19

I really wish they went with angle brackets like everyone else does. I get the argument about not wanting to break existing parsers but this is a significant enough language change to warrant that.

It actually causes ambiguous syntax that isn't easy to solve. See: https://go.googlesource.com/proposal/+/refs/heads/master/des...

    a, b = w  (z)
Is this code doing 2 boolean compares, or is it calling a function with "w" with types x and y?

Re: Golang generics proposal has been accepted

#28

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

This isn’t a new proposal. Go’s maintainers have always been clear that they weren’t against generics per se but we’re against rushing into implementing something without giving sufficient time to consider the options.

Personally I don’t think their time spent considering has resulting in anything better than if they had rushed into a solution (I’m not a fan of this proposal). But that’s just my personal opinion.

Re: Golang generics proposal has been accepted

#29
This is a significant milestone for Go, and I'm extremely happy for the community. I didn't imagine getting here when I first started using the language, and yet here we are.

Special props to Ian Lance Taylor and Robert Griesemer for their continued revisions of drafts, and exemplary discussion with the community in implementing feedback.

Re: Golang generics proposal has been accepted

#30
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.

A more apt comparison is TypeScript to JavaScript, perhaps. Kotlin and Java interop at the bytecode level, but Golang doesn't have that. Gotlin would have to compile to Golang with the same shimming hairiness as TS downleveling to JS.

Well spotted. Though typescript does not fix some of the biggest horrors of JS. Interop is really good as one would expect.
Post reply on HN