Live data from Hacker News

Go: Support for Generic Methods

github.com

61–70 of 288 posts

Re: Go: Support for Generic Methods

#61

This is great. Will be useful for data access methods! As for the detractors, from the first generics proposal this was called out as a "not now", not never. There were questions of implementation. They aren't a super large team, and they try to do things incrementally and do them well.

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

I could be mis-remembering it. I didn't look up and src it.

Re: Go: Support for Generic Methods

#62

Earlier quoted context omitted.

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

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.

so make your own and let's see how you do

Re: Go: Support for Generic Methods

#63
post #58
post #2

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

complaining about things given to you for free

I frankly don't buy into this trope that a lack of monetary cost should shield something from criticism. Anything created by humans for other humans, especially tools meant for getting work done, should certainly be open to evaluation/judgement/critcism, regardless of whether the creator chooses to charge for it.

And it's not like Golang is some freshman student's hobby project; it was created by one of the world's largest tech companies, by people with a strong pedigree in programming language design.

Re: Go: Support for Generic Methods

#64
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).

From another commenter here:

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

Re: Go: Support for Generic Methods

#65
post #2

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

Where did "they" say "we" didn't need generics? That sounds like a bad faith / misinterpretation / straw man; as someone else pointed out, they postponed generics until they figured out the use cases and whatnot. Remember that the generics implementations in other languages (like Java) take up half the spec + implementation - that's not something that Go wanted.

From another commenter here:

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

Re: Go: Support for Generic Methods

#66
post #13
post #5

Earlier quoted context omitted.

So which language had it right from the start? is there a language that has a very low rewrite status?

That’s whataboutism - no language is perfect, but given when go released it’s fair to hold them to a higher standard than languages what were designed 25 years earlier. As an aside - D, Zig, Rust, even typescript got most of the lessons learned from C right

D literally can't even maintain backwards compatibility between minor version updates not to mention a big part of the D community left when D reinvented itself with D2. Among languages it's probably the one that is constantly in a state of flux.

Re: Go: Support for Generic Methods

#68
post #50

Lack of generic methods was really surprising to me when I was first trying to use generics in Go. Nice to see it being actually implemented

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

Re: Go: Support for Generic Methods

#69
post #8

Earlier quoted context omitted.

I know Go is justly criticized for many of its design decisions, but it still feels well-designed and "small" to me in day to day usage when many other languages don't.

Eh, the thing with generics coming late is pretty much what I meant by "organically grown". My best litmus test these days is support for multidimensional arrays because it's always needed at some point in general purpose languages. CL and Ada had it right from the start while C++ needed C++23/26 to get std::mdspan and we still need to wrap it to pass the underlying/owned memory pool around ( https://rosettacode.org/…

Doesn't every language support multidimensional arrays? It's just an array of arrays, no? What am I missing?
Post reply on HN