Go: Support for Generic Methods • Hacker News Board

Re: Go: Support for Generic Methods

#91

Post by stouset » Wed, May 27, 2026, 5:23 PM UTC

skywhopper wrote: post #78

tines wrote: post #64

Earlier quoted context omitted.

From another commenter here: > The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods".

Is anyone actually mad about this, or do people just bring it up to stir the pot? Who cares what the FAQ says? They've worked out a way to add it easily in a backwards compatible way that can solve some problems. They had not identified this solution at the time they wrote the FAQ, and Go has been perfectly usable without this feature for 16 years.

We care that time and time again, when anyone ever brings up a criticism of the language, they’re told that everything is just fine and it’s not a problem and we just don’t get the Go Philosophy. There’s not a problem, stop trying to make Go like every other language, and changing things would make the language more complicated and worse.

Then when the language is inevitably changed for the better, resolving the complaint, suddenly it was always going to happen and it was just a matter of getting the details right.

Every other language community I can think of is more than willing to acknowledge the shortcomings of their language. “Yeah, this kind of sucks in principle but it’s not something that gets in the way in practice” is a fine perspective. So is “this was a tradeoff; we went in this direction and these are the resulting downsides”. But the golang community practically trips over themselves to constantly argue that obvious shortcomings in the language are actually a good thing and we just don’t get it.

Nobody is saying the language shouldn’t improve. We’ve all been begging the language to improve. But we’re also tired of the constant, obvious, and shameless gaslighting from the community whenever things do get better. You aren’t going to like the comparison, but it’s extremely Trumpian.

Re: Go: Support for Generic Methods

#92

Post by xena » Wed, May 27, 2026, 5:26 PM UTC

This will finally let me make the monad library I've been dreaming of for years. Be afraid.

Re: Go: Support for Generic Methods

#93

Post by no_wizard » Wed, May 27, 2026, 5:28 PM UTC

amazingamazing wrote: post #31

jeswin wrote: post #28

Earlier quoted context omitted.

It's a highly successful language because (1) it was backed by Google, and (2) created by Robert Griesemer, Rob Pike, and Ken Thompson. If it came out of anywhere else, it might have struggled even to hit the homepage here.

This logic is easily shown to not hold. Why isn't Carbon, Dart, etc. not really popular then?

Dart was relegated to effectively being Flutter. It was originally intended to supersede JavaScript but no other engine would commit to that. It failed at its initial goal and hasn’t really found a footing outside of Flutter.

Carbon is by its own admittance not ready to use and I think mostly relegated to solving Google’s problems with C++ right now.

Both of them didn’t ship with a standard library as robust as Go’s.

One thing that made Go popular out of the gate is it is extremely good fast to build out robust HTTP services and infrastructure.

This is a very common use case and they tailored Go to be a great fit for it. You can build your entire backend without a single third party module if desired using Go’s standard library and it isn’t terribly complicated to do so.

Re: Go: Support for Generic Methods

#94

Post by maccard » Wed, May 27, 2026, 5:29 PM UTC

9rx wrote: post #83

maccard wrote: post #45

Earlier quoted context omitted.

> Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. iota is a massive kneecap _because_ it's semantically identical to enum in C and Typescript. > Is your argument actually that not having sum types is the massive flaw? Sum types are a useful construct, to be sure, but there are plenty of good languages without them. That's more on the design quirk end, realistic…

> The problem is this - https://www.zarl.dev/posts/enums The only case I see made in there is that it doesn't like how Go implicitly converts consts. While that may be a reasonable criticism, it doesn't have anything to do with iota. It is related to the type system and applies in general. Consider the same problem exhibited here: type Email string func Send(email Email) func() { Send("invalid") } // Converted string…

> It was made abundantly clear when Go was released that it was intended to "feel like a dynamically-typed language".

If I google this quote a comment from you comes up here on this exact topic, where you seem to have completely missed the point there too. If I link to the docs [0], the full quote is "It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language. " So it is a statically typed language first and foremost. If you want to rehash the discussion and tell people that a flawed type system that people have been asking for a solution to for close to a decade [1] you can just re-read the last time the arugments were made as I don't think I'm going to make any headway there.

[0] https://go.dev/doc/ [1] https://github.com/golang/go/issues/19814

Re: Go: Support for Generic Methods

#95

Post by stouset » Wed, May 27, 2026, 5:34 PM UTC

9rx wrote: post #37

maccard wrote: post #29

Earlier quoted context omitted.

Something can be highly succesful in spite of having glaring design flaws. Nobody is claiming go isn't wildly succesful, but it's _in spite_ of these issues. It was clear over a decade ago that iota, gopath, and lack of generics were massive kneecaps to the language; go changing it's mind on those things isn't progress it's just getting the fundamentals wrong. A good example of where they're kind of stuck is date for…

Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. The trouble is that Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing, so by using slightly different syntax, iota, Go avoided the whole confusion of users thinking that enums would behave like sum types instead of actual enums. Is your attempt at making…

> Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript.

So is nil. Care to make the same argument?

Re: Go: Support for Generic Methods

#96

Post by thayne » Wed, May 27, 2026, 5:39 PM UTC

stouset wrote: post #76

tczMUFlmoNk wrote: post #57

Earlier quoted context omitted.

> As for the detractors, from the first generics proposal this was called out as a "not now", not never. What? The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods". There is also some similar discussion of the original generics proposal, with language like "then it's much less clear why we need methods at all". (I'm omitting some context, but I don't feel that it changes…

No, you’re clearly wrong; golang was always going to add support for generic functions. Everyone also wanted and accepted the need for generics. It was always something they wanted to add to the language. Rob Pike never said that that kind of abstraction isn’t what golang is for. It was always just a matter of getting the design right. Go has always been a systems language. It was one when we thought it was going to…

> I personally can’t wait to see what next development will never have been “against the Go philosophy” and definitely not something that gophers argued was perfect the way it was any time misguided malcontents and rabble-rousers wrongly tried to suggest the language wasn’t perfect the way it was.

I really hope it is more ergonomic error handling. Or maybe sum types/discriminated unions.

Re: Go: Support for Generic Methods

#97

Post by jaxlfkkgken » Wed, May 27, 2026, 5:41 PM UTC

skywhopper wrote: post #78

tines wrote: post #64

Earlier quoted context omitted.

From another commenter here: > The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods".

Is anyone actually mad about this, or do people just bring it up to stir the pot? Who cares what the FAQ says? They've worked out a way to add it easily in a backwards compatible way that can solve some problems. They had not identified this solution at the time they wrote the FAQ, and Go has been perfectly usable without this feature for 16 years.

[flagged]

Re: Go: Support for Generic Methods

#98

Post by 9rx » Wed, May 27, 2026, 5:45 PM UTC

maccard wrote: post #94

9rx wrote: post #83

Earlier quoted context omitted.

> The problem is this - https://www.zarl.dev/posts/enums The only case I see made in there is that it doesn't like how Go implicitly converts consts. While that may be a reasonable criticism, it doesn't have anything to do with iota. It is related to the type system and applies in general. Consider the same problem exhibited here: type Email string func Send(email Email) func() { Send("invalid") } // Converted string…

> It was made abundantly clear when Go was released that it was intended to "feel like a dynamically-typed language". If I google this quote a comment from you comes up here on this exact topic, where you seem to have completely missed the point there too. If I link to the docs [0], the full quote is "It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language. " So it i…

> So it is a statically typed language first and foremost.

Right, because that is primarily how it makes things fast. Python is slow largely because it spends an inordinate amount of time trying to figure out what things are. Go knows what things are at compile time because the static type system tells it what things are and thus doesn't have to waste runtime compute on figuring out what things are, aside from when you use the reflect package, like Python does. That was its value-add — that it is kind of like Python, but faster. We already went over this...

> If I link to the docs [0]

I said original announcement, so I'm not sure why you wouldn't look there? Trying to be obtuse on purpose? Regardless, performance was indeed considered more important than being dynamically-typed. After all, if performance wasn't a concern then you'd just use Python. Go exists only because it was solving a problem that wasn't already solved. Slow Python was already solved. Type safety was already solved. It didn't need to go into those territories.

Re: Go: Support for Generic Methods

#99

Post by ncruces » Wed, May 27, 2026, 5:46 PM UTC

nasretdinov wrote: post #68

ncruces wrote: post #50

Earlier quoted context omitted.

To be replaced by the surprise when you figure out these methods don't implement interfaces. Still, in this case, half the feature is better than none at all, IMO.

Generic interfaces are going to be implemented later too if I'm reading correctly. So no real surprises there :). I guess the only surprise yet is that generic interfaces aren't supported, so generic methods physically can't satisfy any interface

I didn't see anything beyond "this doesn't prevent us from doing it" yet.

Did you?

Re: Go: Support for Generic Methods

#100

Post by thayne » Wed, May 27, 2026, 5:51 PM UTC

CamouflagedKiwi wrote: post #32

h1fra wrote: post #2

slowly implementing all the things they said we didn't need

They didn't say they never wanted to do generics, but that they did want to take their time and do them right. Debatable how much they have been "right", although this gets them somewhat closer. And I think they have not been "wrong" in the ways they wanted to avoid (they referenced some issues with Java generics as prior art, although I forget the details).

Depends you who "they" is. If you mean the go development team, then yes, they said they wanted to "take their time and do them right"¹. But there are many "gophers" who did say that there was no need for generics, and that it shouldn't be added to the language.

¹ I would argue that it is really, really hard to add generics to a language after it has already matured, and still "do it right" than to add it in the beginning. At least if you care about backwards compatibility. Backwards compatibility adds a lot of constraints to your generics system that will almost certainly lead to a sub-optimal design. And you will be stuck with a standard library, and a lot of existing ecosystem code that would benefit from generics, but don't because generics didn't exist when they were written. This is a lesson I wish go had learned from Java's generics.