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

81–90 of 288 posts

Re: Go: Support for Generic Methods

#81

Post by someone_19 »

CamouflagedKiwi wrote: post #32
h1fra wrote: 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).

I agree that they were clearly not in a hurry. I disagree that they are doing everything right. I am interested to see how they will fix the 'million dollars mistake'.

Re: Go: Support for Generic Methods

#82

Post by someone_19 »

whoiskevin wrote: post #21
maccard wrote: post #10

Earlier quoted context omitted.

There’s a fine line between being willing to change your mind and getting the basics wrong. Go has repeatedly gotten the basics wrong.

Declaring a highly successful language as having the basics wrong means that you are not correct about the basics that were needed.

So you mean to say that PHP5 and Js from 2007 had a well-founded design?

Re: Go: Support for Generic Methods

#83

Post by 9rx »

maccard wrote: post #45
9rx wrote: post #37

Earlier quoted context omitted.

Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. The trouble is that Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing, so by using slightly different syntax, iota, Go avoided the whole confusion of users thinking that enums would behave like sum types instead of actual enums. Is your attempt at making…

> Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. iota is a massive kneecap _because_ it's semantically identical to enum in C and Typescript. > Is your argument actually that not having sum types is the massive flaw? Sum types are a useful construct, to be sure, but there are plenty of good languages without them. That's more on the design quirk end, realistic…

> The problem is this - https://www.zarl.dev/posts/enums

The only case I see made in there is that it doesn't like how Go implicitly converts consts. While that may be a reasonable criticism, it doesn't have anything to do with iota. It is related to the type system and applies in general. Consider the same problem exhibited here:

    type Email string
    func Send(email Email)
    func() { Send("invalid") } // Converted string const does not satisfy Email type expectations
Perhaps you accidentally offered the wrong link?

It was made abundantly clear when Go was released that it was intended to "feel like a dynamically-typed language". Being able to pass arbitrary values is perfectly in line with a dynamically-typed language. Realistically, the type system in Go is there to give the compiler optimization hints, not to offer type safety. Go was targeted at those wanting to use Python, without the programs being painfully slow to run. How much of a kneecap is implicit type conversion, really, when it is already in line with what the target audience is accustomed to? It is a quirk at best.

Re: Go: Support for Generic Methods

#84

Post by someone_19 »

layer8 wrote: post #24
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.

It’s still annoying ~20 years after Java did the same mistake of not including generics, which was already clear to many people with C++ experience back then.

...and Java didn't even have basic enums or sum types from the beginning. But it had null.

They added enums, they added sealed classes. They're trying to get rid of null (apparently it's really hard). The problem is that in 2012, when go 1.0 was released, this should have been obvious to everyone.

Here's a famous discussion from 2009, three years before the 1.0 release (tldr: facepalm)

https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY

Re: Go: Support for Generic Methods

#85

Post by School-Cotton »

nish__ wrote: post #69
a-french-anon wrote: post #56

Earlier quoted context omitted.

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?

An array of arrays is an extremely inefficient and error-prone way to represent multidimensional arrays.

If I want a 1000x1000 array, representing it physically as a single 1000000-element array requires one allocation, and processing it element-by-element (assuming it's stored in the same order we're iterating over it) is sequential in memory and therefore very efficient.

Representing it as 1000 separate 1000-element arrays requires 1000 allocations, and pointer-chasing every time we move from one row to the next.

Re: Go: Support for Generic Methods

#86

Post by jpc0 »

stouset wrote: post #76
tczMUFlmoNk wrote: post #57

Earlier quoted context omitted.

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

No, you’re clearly wrong; golang was always going to add support for generic functions. Everyone also wanted and accepted the need for generics. It was always something they wanted to add to the language. Rob Pike never said that that kind of abstraction isn’t what golang is for. It was always just a matter of getting the design right. Go has always been a systems language. It was one when we thought it was going to…

> term “systems program” has always meant network middleware that shuttles around JSON and transforms it.

Who are we that has always defined that term that way. For any systems programmer golang has pretty much not been a solution.

Systems is below layer 4 of the network stack, it is building the network stack in the first place.

Re: Go: Support for Generic Methods

#87

Post by masklinn »

jpc0 wrote: post #86
stouset wrote: post #76

Earlier quoted context omitted.

No, you’re clearly wrong; golang was always going to add support for generic functions. Everyone also wanted and accepted the need for generics. It was always something they wanted to add to the language. Rob Pike never said that that kind of abstraction isn’t what golang is for. It was always just a matter of getting the design right. Go has always been a systems language. It was one when we thought it was going to…

> term “systems program” has always meant network middleware that shuttles around JSON and transforms it. Who are we that has always defined that term that way. For any systems programmer golang has pretty much not been a solution. Systems is below layer 4 of the network stack, it is building the network stack in the first place.

I think your sarcasm detector has gone missing chief.

Re: Go: Support for Generic Methods

#88

Post by rootnod3 »

xscott wrote: post #23
rootnod3 wrote: post #19

Earlier quoted context omitted.

Which Scheme are we talking about? R5RS? R7RS-small? R6RS? With SRFIs? Without? Which scheme? Is it `(library...)` or `(define-module...)`?

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 ECL code and throw it into SBCL or LispWorks.

Re: Go: Support for Generic Methods

#89

Post by cyphar »

stouset wrote: post #76
tczMUFlmoNk wrote: post #57

Earlier quoted context omitted.

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

No, you’re clearly wrong; golang was always going to add support for generic functions. Everyone also wanted and accepted the need for generics. It was always something they wanted to add to the language. Rob Pike never said that that kind of abstraction isn’t what golang is for. It was always just a matter of getting the design right. Go has always been a systems language. It was one when we thought it was going to…

> The community didn’t need to independently invent godep, then glide, then govendor, then dep, before the core team finally shipped modules. That was just enthusiastic parallel exploration of a problem space that everyone agreed was a problem. When modules arrived, everyone was simply relieved that this obvious stopgap was finally replaced.

And of course, it was replaced with a more correct implementation that was incompatible with that awful stopgap because semantic correctness trumps all. vendor/ trees and GOPATH were never meant to be remotely compatible, and don't you know -- the Go compatibility guarantee(TM) doesn't apply to misuse of GOPATH to work around shortcomings^Wwell-considered designs of Go, even if it breaks the largest Go project at the time!

(/s It still shocks me that they decided to drop "src" from vendor/src and break compatibility when they finally got around to supporting vendoring despite every tool using it. And symlinks don't work because Plan 9 is the future!!)

Re: Go: Support for Generic Methods

#90

Post by nish__ »

School-Cotton wrote: post #85
nish__ wrote: post #69

Earlier quoted context omitted.

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

An array of arrays is an extremely inefficient and error-prone way to represent multidimensional arrays. If I want a 1000x1000 array, representing it physically as a single 1000000-element array requires one allocation, and processing it element-by-element (assuming it's stored in the same order we're iterating over it) is sequential in memory and therefore very efficient. Representing it as 1000 separate 1000-elemen…

I see. That makes sense.
Post reply on HN