6 ms·

Deconstructing Go Type Parameters

140 points by psxuaw 3y ago

carterschonwald 3y ago
I’m almost a grey beard in typed functional programming and I’m actually confused by this.
- sharno 3y ago
  The language and way of writing feels very weird. The concepts are simple genetics but for some reason I don’t get the idea of underlying type. Wish they used a more formal language
  - riwsky 3y ago
    it's not doing anything particularly interesting from a formal perspective. If you're familiar with Haskell's newtype deriving, the tilde is solving the same problem—just at the use-sites of the type instead of at the declaration site. The types it tends to be useful for are the types that Go allows as constants (https://go.dev/ref/spec#Constants https://go.dev/ref/spec#Constants), which tend to be the type classes that modern Preludes will overload the literals for.
  - carterschonwald 3y ago
    That’s exactly it… every time I’ve tried to find detailed docs about go generics I just find really confusing prose with examples
happytoexplain 3y ago
Wow, I'm not super happy about the syntax of this language. I'm familiar with what each paragraph is describing from multiple other languages, but I can't even guess how some of the syntax here maps onto those other languages, even with the explanations.
- jrockway 3y ago
  You have to click through to read the assignability rules. A very short summary is that people often create new types based on core types. For example: type Name string Now you can define methods on Name: func (n Name) Foo() { ... } ... x := Name("Me") x.Foo() But, you can't use Name and string interchangeably: func StringFoo(x string) { ... } StringFoo(Name("Me")) // does not compile In the case of generics, maybe you want to write a function that can handle any string: func Bar[T string](x T) { ... } Bar(Name("Me")) Bar("Me") This doesn't compile, because Name isn't assignable to string. The fix is to declare the type parameter as [T ~string]. (The compile error suggests this, in fact. You can also write string(Name("Me")) but if T were being used as the type of the return value, the returned value would be type string, not type Name.) In the case of slices, it can be more complicated. These types all seem similar, but aren't the same: []string []Name type StringSlice []string type NameSlice []Name The idea of the article is figuring out how to write a generic type signature that would accept any of these and return the right type. Finally, you can rename types and use them interchangeably if you don't want the "safety" of making a new type: type Name = string Now you can't write methods on Name, but you can use Name and string interchangably. (This, incidentally, is how "any" works. The package builtin contains "type any = interface{}".) If the complaint about syntax is not using <T type> to denote type parameters like Java and C++, [] simplifies the parser. You can read the original generics proposal for all the details.
  - VirusNewbie 3y ago
    All that instead of type classes eh?
    - valenterry 3y ago
      Indeed. Pains me to see what they are doing while not learning from existing and well established language patterns. I understand that Go wants (or wanted) to stay "simple" but now it seems to become the worst of two worlds: it's neither simple anymore but also doesn't benefit from high level language features like typeclasses because it's too late to add them now.
parhamn 3y ago
It really doesn't help that the major (perhaps only?) official resources on generics in golang are these blog posts [1][2] and the spec. And now this blog post. The whole "what type am I getting"/make()ing is really tricky (as outlined in this doc) especially when its a pointer/interface/slice/etc. And a lot of feels like it doesn't need to be as much of a complex decision tree as it is. Is there any other documentation on this stuff that I'm missing? Theres a lot of complication buried in golang people don't talk about that much. nil vs empty slices, interface{} and any behavior differences, make() and what it would do for various type scenarios, impossible to remember channel semantics (which ones panic again?). Of course, theres always a good explanation for why it is the way it is, but for a language so opinionated, stronger opinions on better DX in the deeper parts would be great. [1] https://go.dev/blog/intro-generics https://go.dev/blog/intro-generics [2] https://go.dev/doc/tutorial/generics https://go.dev/doc/tutorial/generics
- jrockway 3y ago
  Pointing people at the spec is probably the best decision the Go team ever made. Why wonder about things when you can have true authority in an honestly very short piece of text? No guessing, just an exact description of what's going to happen. (I was in there recently reading about operator precedence recently and discovered an operator I didn't know existed, "bit clear (AND NOT)", &^. Amusingly, I needed to do that operation but wasn't sure if I needed parentheses for X & (^Y) or not. I still don't know why it's a dedicated operator, however. The spec rarely says WHY, just WHAT.)
  - Groxx 3y ago
    It does help that the spec (and memory model!) is quite good and reasonably concise. I send people there as often as possible when they start getting interested in learning things For Real, blogspam is rarely anywhere near as useful despite being multiple times longer. (Which is not meant to claim this article is blogspam - making recommendations with examples is quite different from a spec, and we definitely need recommendations)
    - 3y ago
Groxx 3y ago
I suppose this is necessary because this: func clone[S ~[]any)(s S) S would only allow things with an underlying type of []interface{}, not "any type" as an inferred type... and that applies to the final example too: // allows any collection of stringable things func WithStrings[S ~[]E, E interface { String() string }]( // allows only things like: // []interface { String() string }{...} // and named types like that, but not: // []strings.Builder{...} // because that isn't the same collection type, // it's just a collection of compatible elements func WithStrings[S ~[]interface { String() string }](...) I guess this is the price to pay to avoid introducing co/contra variance? It may be worth it, and it seems likely that it would be a thing you can improve without breaking compatibility.
mutatio 3y ago
I'm not sure I'm following the preamble about the nuances of a slice with a zero capacity allocating a new backing array, given the fact that if I follow the link to the docs and then to the source, the implementation is exactly how I would have expected it to be done: append(S([]E{}), s...) - which of course is different and would make the preamble redundant.
- TheDong 3y ago
  My guess is that originally, the post didn't have "// body omitted" below. The actual implementation requires having the `S` type to refer to, and the point of this post is to explain why the `S` type has to be named. By writing it as they did, the "// body omitted" one _could_ have had the same body, even without an 'S' type to refer to. I bet the "// body omitted" bit of the post got refactored, and the reason for making the first one different from the stdlib impl got lost.
- aatd86 3y ago
  The generic function is cloning a slice so you need to allocate a new backing array. (think deep-copy) Here that's just a one-liner that works. I need to check but I think that if you need to keep the same capacity, you may want to preallocate manually.
  - mutatio 3y ago
    I understand that, my point solely rest around defining the clone function from the slices package in the article, explaining why, yet the actual implementation is different. The source code I found via the docs doesn't consider capacity, it merely uses a empty construct and appends.
    - aatd86 3y ago
      Ah you're right... It's rather a shallow copy. Good point. I have no clue either. Maybe you can open an issue?
hknmtt 3y ago
I am a Go fan and have been coding in it for years, but this crap: func Clone[S ~[]E, E any](s S) S { return append(s[:0:0], s...) } looks just like Rust, which has the fugliest syntax I have ever seen. Personally I use maybe 3 or 4 generic functions to work with arrays(oh, sorry SLICES), otherwise I do not touch them. Could not care less about them and all that noise they caused.
- TheDong 3y ago
  In go, the stdlib impl is actually: func Clone[S ~[]E, E any](s S) S { if s == nil { return nil } return append(S([]E{}), s...) } For comparison, `vec.clone()` in the rust stdlib is: pub trait Clone: Sized { fn clone(&self) -> Self; } impl<T: Clone> Clone for Vec<T> { fn clone(&self) -> Self { <[T]>::to_vec(&**self) } } I think the rust one is much easier to read. The go one has an if statement, which means the go one has higher cyclomatic complexity, and is thus harder to understand and reason about. The rust one does have "&**self", which looks a little strange perhaps, but overall seems simpler than the go one.
  - qprofyeh 3y ago
    What is “&**self” called?
    - gdprrrr 3y ago
      It reborrows `*self` als a slice. I prefer The Methode `as_slice` which does the same.
    - TheDong 3y ago
      It is so simple it does not have a name. It is simply a double deref + borrow. Since "deref" can be implemented differently for each type, you cannot know what it does in general, but in this case '*Vec<T>' turns it into a '[T]'. If you compile in release mode, all of the following implementations of 'clone' will emit identical assembly: <[T]>::to_vec(&**self) <[T]>::to_vec(&self[..]) <[T]>::to_vec(self.as_slice()) self.as_slice().to_vec() The stdlib picked the coolest looking one. Can't fault them for that.
dolmen 3y ago
I have a question that this post doesn't answer: is the order of type parameters significant? Is there a canonical way, an idiomatic style for the order? Example: func Clone1[S ~[]E, E any](s S) S { return append(s[:0:0], s...) } vs func Clone2[E any, S ~[]E](s S) S { return append(s[:0:0], s...) }
- xyzzy_plugh 3y ago
  Is the order of function parameters significant?
  - deleted 3y ago
    [deleted]
  - dolmen 3y ago
    Fair. Type parameters is significant when you call the function with explicit type parameters. Ex: clone1 := Clone1[[]string, string] But when type parameters values are infered, the order looks much less important for the API designer. Do we have rules (idioms) somewhere about a recommended order for such parameter types?
- xh-dude 3y ago
  The logic for inferring types plays out better for the first. Go limits the depth of searching for type inferences, to keep compilation fast/small/simple. It’s always possible to be more explicit but nice to infer when calling generic code.

140 points by psxuaw 3y ago

carterschonwald 3y ago

I’m almost a grey beard in typed functional programming and I’m actually confused by this.

sharno 3y ago
The language and way of writing feels very weird. The concepts are simple genetics but for some reason I don’t get the idea of underlying type. Wish they used a more formal language
- riwsky 3y ago
  it's not doing anything particularly interesting from a formal perspective. If you're familiar with Haskell's newtype deriving, the tilde is solving the same problem—just at the use-sites of the type instead of at the declaration site. The types it tends to be useful for are the types that Go allows as constants (https://go.dev/ref/spec#Constants https://go.dev/ref/spec#Constants), which tend to be the type classes that modern Preludes will overload the literals for.
- carterschonwald 3y ago
  That’s exactly it… every time I’ve tried to find detailed docs about go generics I just find really confusing prose with examples

happytoexplain 3y ago

Wow, I'm not super happy about the syntax of this language. I'm familiar with what each paragraph is describing from multiple other languages, but I can't even guess how some of the syntax here maps onto those other languages, even with the explanations.

jrockway 3y ago
You have to click through to read the assignability rules. A very short summary is that people often create new types based on core types. For example: type Name string Now you can define methods on Name: func (n Name) Foo() { ... } ... x := Name("Me") x.Foo() But, you can't use Name and string interchangeably: func StringFoo(x string) { ... } StringFoo(Name("Me")) // does not compile In the case of generics, maybe you want to write a function that can handle any string: func Bar[T string](x T) { ... } Bar(Name("Me")) Bar("Me") This doesn't compile, because Name isn't assignable to string. The fix is to declare the type parameter as [T ~string]. (The compile error suggests this, in fact. You can also write string(Name("Me")) but if T were being used as the type of the return value, the returned value would be type string, not type Name.) In the case of slices, it can be more complicated. These types all seem similar, but aren't the same: []string []Name type StringSlice []string type NameSlice []Name The idea of the article is figuring out how to write a generic type signature that would accept any of these and return the right type. Finally, you can rename types and use them interchangeably if you don't want the "safety" of making a new type: type Name = string Now you can't write methods on Name, but you can use Name and string interchangably. (This, incidentally, is how "any" works. The package builtin contains "type any = interface{}".) If the complaint about syntax is not using <T type> to denote type parameters like Java and C++, [] simplifies the parser. You can read the original generics proposal for all the details.
- VirusNewbie 3y ago
  All that instead of type classes eh?
  - valenterry 3y ago
    Indeed. Pains me to see what they are doing while not learning from existing and well established language patterns. I understand that Go wants (or wanted) to stay "simple" but now it seems to become the worst of two worlds: it's neither simple anymore but also doesn't benefit from high level language features like typeclasses because it's too late to add them now.

parhamn 3y ago

It really doesn't help that the major (perhaps only?) official resources on generics in golang are these blog posts [1][2] and the spec. And now this blog post. The whole "what type am I getting"/make()ing is really tricky (as outlined in this doc) especially when its a pointer/interface/slice/etc. And a lot of feels like it doesn't need to be as much of a complex decision tree as it is. Is there any other documentation on this stuff that I'm missing? Theres a lot of complication buried in golang people don't talk about that much. nil vs empty slices, interface{} and any behavior differences, make() and what it would do for various type scenarios, impossible to remember channel semantics (which ones panic again?). Of course, theres always a good explanation for why it is the way it is, but for a language so opinionated, stronger opinions on better DX in the deeper parts would be great. [1] https://go.dev/blog/intro-generics https://go.dev/blog/intro-generics [2] https://go.dev/doc/tutorial/generics https://go.dev/doc/tutorial/generics

jrockway 3y ago
Pointing people at the spec is probably the best decision the Go team ever made. Why wonder about things when you can have true authority in an honestly very short piece of text? No guessing, just an exact description of what's going to happen. (I was in there recently reading about operator precedence recently and discovered an operator I didn't know existed, "bit clear (AND NOT)", &^. Amusingly, I needed to do that operation but wasn't sure if I needed parentheses for X & (^Y) or not. I still don't know why it's a dedicated operator, however. The spec rarely says WHY, just WHAT.)
- Groxx 3y ago
  It does help that the spec (and memory model!) is quite good and reasonably concise. I send people there as often as possible when they start getting interested in learning things For Real, blogspam is rarely anywhere near as useful despite being multiple times longer. (Which is not meant to claim this article is blogspam - making recommendations with examples is quite different from a spec, and we definitely need recommendations)
  - 3y ago

Groxx 3y ago

I suppose this is necessary because this: func clone[S ~[]any)(s S) S would only allow things with an underlying type of []interface{}, not "any type" as an inferred type... and that applies to the final example too: // allows any collection of stringable things func WithStrings[S ~[]E, E interface { String() string }]( // allows only things like: // []interface { String() string }{...} // and named types like that, but not: // []strings.Builder{...} // because that isn't the same collection type, // it's just a collection of compatible elements func WithStrings[S ~[]interface { String() string }](...) I guess this is the price to pay to avoid introducing co/contra variance? It may be worth it, and it seems likely that it would be a thing you can improve without breaking compatibility.

mutatio 3y ago

I'm not sure I'm following the preamble about the nuances of a slice with a zero capacity allocating a new backing array, given the fact that if I follow the link to the docs and then to the source, the implementation is exactly how I would have expected it to be done: append(S([]E{}), s...) - which of course is different and would make the preamble redundant.

TheDong 3y ago
My guess is that originally, the post didn't have "// body omitted" below. The actual implementation requires having the `S` type to refer to, and the point of this post is to explain why the `S` type has to be named. By writing it as they did, the "// body omitted" one _could_ have had the same body, even without an 'S' type to refer to. I bet the "// body omitted" bit of the post got refactored, and the reason for making the first one different from the stdlib impl got lost.
aatd86 3y ago
The generic function is cloning a slice so you need to allocate a new backing array. (think deep-copy) Here that's just a one-liner that works. I need to check but I think that if you need to keep the same capacity, you may want to preallocate manually.
- mutatio 3y ago
  I understand that, my point solely rest around defining the clone function from the slices package in the article, explaining why, yet the actual implementation is different. The source code I found via the docs doesn't consider capacity, it merely uses a empty construct and appends.
  - aatd86 3y ago
    Ah you're right... It's rather a shallow copy. Good point. I have no clue either. Maybe you can open an issue?

hknmtt 3y ago

I am a Go fan and have been coding in it for years, but this crap: func Clone[S ~[]E, E any](s S) S { return append(s[:0:0], s...) } looks just like Rust, which has the fugliest syntax I have ever seen. Personally I use maybe 3 or 4 generic functions to work with arrays(oh, sorry SLICES), otherwise I do not touch them. Could not care less about them and all that noise they caused.

TheDong 3y ago
In go, the stdlib impl is actually: func Clone[S ~[]E, E any](s S) S { if s == nil { return nil } return append(S([]E{}), s...) } For comparison, `vec.clone()` in the rust stdlib is: pub trait Clone: Sized { fn clone(&self) -> Self; } impl<T: Clone> Clone for Vec<T> { fn clone(&self) -> Self { <[T]>::to_vec(&**self) } } I think the rust one is much easier to read. The go one has an if statement, which means the go one has higher cyclomatic complexity, and is thus harder to understand and reason about. The rust one does have "&**self", which looks a little strange perhaps, but overall seems simpler than the go one.
- qprofyeh 3y ago
  What is “&**self” called?
  - gdprrrr 3y ago
    It reborrows `*self` als a slice. I prefer The Methode `as_slice` which does the same.
  - TheDong 3y ago
    It is so simple it does not have a name. It is simply a double deref + borrow. Since "deref" can be implemented differently for each type, you cannot know what it does in general, but in this case '*Vec<T>' turns it into a '[T]'. If you compile in release mode, all of the following implementations of 'clone' will emit identical assembly: <[T]>::to_vec(&**self) <[T]>::to_vec(&self[..]) <[T]>::to_vec(self.as_slice()) self.as_slice().to_vec() The stdlib picked the coolest looking one. Can't fault them for that.

dolmen 3y ago

I have a question that this post doesn't answer: is the order of type parameters significant? Is there a canonical way, an idiomatic style for the order? Example: func Clone1[S ~[]E, E any](s S) S { return append(s[:0:0], s...) } vs func Clone2[E any, S ~[]E](s S) S { return append(s[:0:0], s...) }

xyzzy_plugh 3y ago
Is the order of function parameters significant?
- deleted 3y ago
  [deleted]
- dolmen 3y ago
  Fair. Type parameters is significant when you call the function with explicit type parameters. Ex: clone1 := Clone1[[]string, string] But when type parameters values are infered, the order looks much less important for the API designer. Do we have rules (idioms) somewhere about a recommended order for such parameter types?
xh-dude 3y ago
The logic for inferring types plays out better for the first. Go limits the depth of searching for type inferences, to keep compilation fast/small/simple. It’s always possible to be more explicit but nice to infer when calling generic code.