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

Go: Support for Generic Methods

github.com

Post reply on HN
Print view View original

141–150 of 288 posts

Re: Go: Support for Generic Methods

#141

Post by assbuttbuttass »

xena wrote: post #92

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

It's (sadly) still not possible to express monads with this change, since generic methods can't implement interfaces. You'd probably want something like:

    type Monad[T any] interface {
        Bind[U any](func(T) Monad[U])
    }
However this requires the Bind method to be generic, which still isn't allowed in an interface

Re: Go: Support for Generic Methods

#142

Post by array_key_first »

the_gipsy wrote: post #136
Matl wrote: post #126

Earlier quoted context omitted.

Yeah, because software is not meant to evolve and people are not meant to either.

You're not meant to gaslight about the evolution of software.

Changing your mind is not gaslighting, people just change their mind sometimes.

Re: Go: Support for Generic Methods

#143

Post by array_key_first »

pizza234 wrote: post #71
a-french-anon wrote: post #4

Earlier quoted context omitted.

Maybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both.

It isn't realistic to expect a design to be "proper in first place" because requirements change; my opinion is indeed the opposite - I find it natural for programming languages to have a (sort of) lifespan, and for new ones to (sort of) take their place.

Sure but literally everyone and their mom said these features were needed and then Go team said "nuh uh!!!" But, as it turns out, they are needed because they solve real problems, and are not just fake complexity like some people strawman.

Hopefully next they can add some error handling syntax and controls.

Re: Go: Support for Generic Methods

#144

Post by 9rx »

EdwardDiego wrote: post #139
kbolino wrote: post #123

Earlier quoted context omitted.

Generic interfaces already exist. Generic interface methods, which would be relevant, are not planned. The reason is outlined early in the proposal: nobody knows how to implement them efficiently. Rust has the same problem, for what it's worth: dispatchable functions on dyn-compatible traits cannot be generic [1]. [1]: https://doc.rust-lang.org/reference/items/traits.html#r-item...

Is it because of the kinda built-in duck typing, for want of a better word? The thing where if you have a method (or methods) that matches the signature of method(s) of an interface, you implement the interface without explicitly declaring so?

> for want of a better word

Structural typing is the term typically used to describe "static duck typing".

Re: Go: Support for Generic Methods

#145

Post by tialaramex »

dwattttt wrote: post #134
tialaramex wrote: post #129

Earlier quoted context omitted.

Or to look at that from another angle, if you were to define a Trait which has generic methods that Trait won't be "dyn-compatible" meaning that you can't do dynamic dispatch with this trait, which may be irrelevant to you (if you don't want dynamic dispatch anyway) or a showstopper (if you needed it, now your project won't compile).

That is another way of looking at it, but given the topic, you're gonna have to expand or contextualise that. I Rust a fair bit, and only barely follow.

Actually in hindsight I think my perspective was less helpful because you can write a dyn compatible trait with a generic method it's just that you can't call the method via the trait objects, dynamic dispatch isn't possible for your function. So the original way to think about it was superior.

Re: Go: Support for Generic Methods

#146

Post by jamesfinlayson »

stouset wrote: post #91
skywhopper wrote: post #78

Earlier quoted context omitted.

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 comp…

Yeah, I worked with a guy in the late 2010s - one of the most painful people I've ever worked with - who would tell anyone that would listen that Go (as it was in 2018) was the perfect programming language - it had all the features you'd ever need - no more, no less. It doesn't need generics, the package management story is fine etc. Thankfully he's been out of my life for a long time now but I believe he's still writing Go, and I bet that he's telling anyone that will listen that Go (as it is in 2026) is the perfect programming language and that its implementation of generics was necessary and perfect etc.

He wasn't the only one but he certainly took it to the extreme.

Re: Go: Support for Generic Methods

#147

Post by 9rx »

Cthulhu_ wrote: post #54
throwpikerob wrote: post #42

A sad day for Go, the pHDs have won, simplicity has died.

It only died if you actually applied it in your own codebase - as with any feature, using it is optional.

Code is written to be read, and typically for other people to read. So, in practice, it is only optional if everyone else agrees to not use it.

Re: Go: Support for Generic Methods

#148

Post by thayne »

> Go doesn't support such generic interface methods because we don't know how to implement (calls of) them, or at least we don't know how to implement them efficiently.

I don't really understand this argument. I read the discussion linked to[1], and yeah, monomorphization approaches (whether at compile time, link time, or runtime with JIT) are obviously going to be difficult or impossible, but the reason against using runtime reflection is mostly that it's slow. But that runtime reflection is exactly how you would work around it today.

For the Identity example, could the interface be compiled to be basically equivalent to:

Identity(any) any

and then at the callsite add a cast of the return type to T?

I suppose primative non-pointer types add a bit of a wrinkle but even if it generic methods was restricted to pointer types, that's better than nothing. And the number of those types is relatively small, so when the implementation is compiled it could just instantiate method implementations for all the primative types, if they apply, and then maybe remove them if they aren't needed at link time.

Of course it's also possible there is some detail I've missed.

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

Re: Go: Support for Generic Methods

#149

Post by zarzavat »

h1fra wrote: post #2

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

Watching Go's development is like reliving the development of Java (which also didn't have generics at first), but over decades instead of years. Cannot wait for Go to implement an error handling system in the 2030s.

Re: Go: Support for Generic Methods

#150

Post by zarzavat »

9rx wrote: post #16
h1fra wrote: post #2

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

Of course, if you go back and watch the original Go announcement it said that it would need generics once they figured out how to do it. And when the first version of generics landed it was said that generic methods would be added later, once they figured out how to do it. So that isn't applicable here. The need was always recognized.

If Go had just taken an off-the-shelf implementation of generics in 2009 then they could have spent the last 16 years deliberating over something useful, rather than attempting to reinvent programming language theory.

The impression I have always gotten from Go's designers is that they are rather arrogant and averse to the idea of using other people's work. They want to develop everything from first principles, but by so doing end up with poor reinventions of well-studied concepts.

Post reply on HN