Go: Support for Generic Methods • Hacker News Board

Re: Go: Support for Generic Methods

#131

Post by xscott » Wed, May 27, 2026, 10:39 PM UTC

rootnod3 wrote: post #88

xscott wrote: post #23

Earlier quoted context omitted.

Heh, I'd probably take R4RS with define-syntax :-)

I mean, good choice, but you see the point, right? As much as ANSI CL has it's flaws, it has a standard, as much of a mixed bag it might be. Scheme is just a general potpourri of "we kinda have a guideline, but do whatever". I would very much prefer scheme if the different implementations had a working standard. But I can't take my Chez-scheme code and throw it into Guile-scheme. But pretty good chance I can take my…

> you see the point, right?

Bah, I think this debate was already old when I first saw people arguing it on comp.lang.lisp in the 90s. I don't have a dog in this fight other than to reject the notion that Common Lisp is "coherent" and not "organically grown".

The original Scheme belongs in the category of languages like Standard ML and SmallTalk, where a small, careful, and talented group designed them with focus. Common Lisp seems like a bunch of smart people with competing interest and legacy baselines tried to meet in the middle. To the extent CL is more pragmatic, it's another example of "Worse is Better".

Re: Go: Support for Generic Methods

#132

Post by zephen » Wed, May 27, 2026, 10:48 PM UTC

bonesss wrote: post #111

xena wrote: post #92

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

A monad library in go can really on have one name… …

Mo-go?

Re: Go: Support for Generic Methods

#133

Post by sdevonoes » Wed, May 27, 2026, 10:51 PM UTC

throwpikerob wrote: post #42

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

It certainly makes readability of Go code harder.

Re: Go: Support for Generic Methods

#134

Post by dwattttt » Wed, May 27, 2026, 10:52 PM UTC

tialaramex wrote: post #129

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

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.

Re: Go: Support for Generic Methods

#135

Post by throwaway894345 » Wed, May 27, 2026, 10:53 PM UTC

bonesss wrote: post #111

xena wrote: post #92

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

A monad library in go can really on have one name… …

Mongo

Re: Go: Support for Generic Methods

#136

Post by the_gipsy » Wed, May 27, 2026, 10:57 PM UTC

Matl wrote: post #126

the_gipsy wrote: post #125

Earlier quoted context omitted.

You just can never trust what the go team says.

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.

Re: Go: Support for Generic Methods

#137

Post by dnnddidiej » Wed, May 27, 2026, 11:09 PM UTC

xena wrote: post #92

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

Can we have Exception monads? Asking for friend.

Re: Go: Support for Generic Methods

#138

Post by metaltyphoon » Wed, May 27, 2026, 11:21 PM UTC

ivanjermakov wrote: post #127

TheChaplain wrote: post #3

Earlier quoted context omitted.

It's not a bad thing to realize that one can be wrong and then strive for change.

Worst thing a programming language can do is introduce core semantics changes after 1.0. See Python 2 -> 3 and Zig's *gates.

Except Zig is not 1.0

Re: Go: Support for Generic Methods

#139

Post by EdwardDiego » Thu, May 28, 2026, 12:06 AM UTC

kbolino wrote: post #123

nasretdinov wrote: post #68

Earlier quoted context omitted.

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

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?

Re: Go: Support for Generic Methods

#140

Post by EdwardDiego » Thu, May 28, 2026, 12:10 AM UTC

sdevonoes wrote: post #133

throwpikerob wrote: post #42

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

It certainly makes readability of Go code harder.

If generics replace code generation or hand coding a concrete implementation for specific types or... operating against interface{} and then switching based on runtime type, then I strongly disagree that it makes reading Go code harder, it makes it, IMO, easier.

But that's the thing, it's just IMO.