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…
Go: Support for Generic Methods
61–70 of 288 posts
Re: Go: Support for Generic Methods
#62Earlier 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.
Re: Go: Support for Generic Methods
#63slowly implementing all the things they said we didn't need
complaining about things given to you for free
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
#64slowly 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).
> 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
#65slowly 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.
> 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
#66Earlier 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
Re: Go: Support for Generic Methods
#67Re: Go: Support for Generic Methods
#68Lack 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.
Re: Go: Support for Generic Methods
#69Earlier 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/…
Re: Go: Support for Generic Methods
#70Chasing a perceived gap between language features and user expectations has been and continues to be the greatest error in the leadership of Go.