Hacker News Reader

Comment by kubb | Hacker News Reader

I wonder if the limitation of not allowing type parameters for methods came from wanting to prevent people from using it for certain features that would be considered "too complicated for Go", or from it being "too complicated to support" or from "we won't be needing it anyways".

Another option to circumvent this is to use top-level functions, and accept the receiver as the first argument of the function. This is effectively the same thing, the only thing it's missing is the object.method() syntax that's familiar to OO programmers.

View on HN

No need to wonder. The proposal goes into lengthy detail as to why they are not included.

There is hope that they will be added in the future, but solutions to the problems will need to be found first.

I wouldn't call it lengthy, but if anyone is wondering, the proposal points out that parametrized methods don't have an obvious behavior _inside interfaces_. No mention of why they left them out in non-interface types.

Yeah they are just being ignorant once again. Even "static" interface usage, a la Rust Traits, is fine. But Go doesn't distinguish between the static stuff and the dynamic vtable stuff very well at all.

That's the problem they should fix.

> Yeah they are just being ignorant once again.

That's the core problem. Anyone who truly understands generics has shown no willingness to work on Go. The only reason it has progressed as far as it has is because a third-party consultant was temporarily hired to develop what was dubbed Featherweight Go to act as a proof of concept.

It turns out that the intersection of people who care about generics in Go and those those who aren't armchair coders unable to comprehend the domain themselves is limited to very few people. As you know well from your armchair.

It seems plausible that some people who might otherwise want to have decided not to given the very vocal contingent of the Go community that's been opposed to generics. After almost a decade of people saying Go didn't need generics, it seems like it would be hard to convince people who are knowledgeable in that field that their efforts would be welcome.

The core Go team has been working on generics since the pre-1.0 days and have submitted many different generics proposals over the years to reflect that. They all, until the latest one, failed for one reason or another, but shared property of them all was being created by those who were not experts in the domain. It is why the latest incarnation brought in an external consultant to help guide the team in the right direction.

There was clearly always interest from the project itself. There may have been some random naysayers on the internet who act like they are opposed, but you'll find people acting every way imaginable on the internet. I really doubt anyone actually refrained from working on the project because an internet troll wrote something silly.

what is the major difference of go generics vs say c# or swift generics that makes the long wait worth it for go?

was there any major breakthroughs?

I don't expect you will find any major difference, hence why the number of people who cared about generics in Go was effectively nobody and why very few were stepping up to contribute: They already had many other languages to choose from.

It seems significant (major? I dunno) that Go doesn’t have inheritance or subclassing or co-/contra-variance.

You sound like someone who doesn’t know very much about Go.

In Go any type can implement interfaces. A type doesn't declare which interfaces it implements.

That doesn't seem like a relevant objection?

If structs support generic methods but interfaces don't then nothing happens, everything just works as you'd expect (whithin those limitations). A method which isn't part of the interface is not under consideration, so the generic methods have no bearing on the interfaces the object could or would implement.

The reverse would be an issue, but this is not.

> No mention of why they left them out in non-interface types.

Actually it does:

"Or, we could decide that parameterized methods do not, in fact, implement interfaces, but then it's much less clear why we need methods at all. If we disregard interfaces, any parameterized method can be implemented as a parameterized function."

https://go.googlesource.com/proposal/+/refs/heads/master/des...

Except that reflection-based tools work with methods but not functions.

Yes, but reflection is part of the problem:

"And even that traversal is not sufficient in the general case when type reflection gets involved, as reflection might look up methods based on strings input by the user. So in general instantiating parameterized methods in the linker might require instantiating every parameterized method for every possible type argument, which seems untenable."

So methods with type parameters would a) not be usable with interfaces and b) not be usable with reflection.

Reply on news.ycombinator.com