5 ms·

I haven't been following these proposals and I want generics of some kind in Go (I've had my fill of code generation), but good God does the proposed syntax of

by cjslep 7y ago

I haven't been following these proposals and I want generics of some kind in Go (I've had my fill of code generation), but good God does the proposed syntax of using parentheses for yet another thing (in addition to method receiver, parameters, return types, logical grouping, arguments) make the language suddenly feel cluttered and hard to read.

eternalban 7y ago
And it is basically notation noise. The idea is to inform the compiler as to which type names are generic. // proposed func Print2(type T1, T2)(s1 []T1, s2 []T2) { ... } vs // less noise func Print2(s1 []'T1, s2 []'T2) { ... } This proposal does -not- seem to be informed by the same 'outer space' mindset that gave us the Go language. A reminder that mere capitalization in Go language informs visibility and access. Beyond mere syntax issues, the semantics of generics itself is adding huge complexity to what is a very capable and accessible 80% language.
- Insanity 7y ago
  I really don't think generics (or contracts) will benefit the language. Most people who miss it are just missing the collection frameworks from Java/C#, and there are solutions to this anyway. (go:generate being one of them if you really need collections for X types). I did miss generics when I first started writing Go, but after doing so for about a year at work and 2 years before that, I don't find me missing them at all.
  - JyB 7y ago
    I have the exact same feeling. I was using generics extensively in C# particularly. I don't miss them at all after having spent a lot of time working with and understanding Go. I can't help but feel it will just make the language far less attractive in the long run.
    - Insanity 7y ago
      Yeah I believe so as well. All languages having the same features would also be a downside. Just make a choice and stand by it. (Like Haskell, they are not pressured into doing things just because Java does so).
      - danieldk 7y ago
        Like Haskell, they are not pressured into doing things just because Java does so I do not mean this as a criticism of Haskell, but Haskell has a lot of GHC-specific language extensions: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html https://downloads.haskell.org/~ghc/latest/docs/html/users_gu... I am not sure it qualifies as making a choice and standing by it.
  - eternalban 7y ago
    I agree. I am not missing generics at all. It's a pain once is a while but it passes. But addressing that minor downside in no way in my mind justifies destroying what actually makes Go an effective language.
- ithkuil 7y ago
  interesting > func Print2(s1 []'T1, s2 []'T2) { ... } where would you add the claim that T1 and T2 must obey some named "contract"?
  - NateDad 7y ago
    They'd both be T1 in that case. T1 T2 means they're different contracts.
    - coldtea 7y ago
      I don't think parent implied that they should obey the same construct. He asked where you'd denote the contracts each type much obey (e.g. the focus being: in which place, assuming, I guess, that you intent to stray from the current proposal of defining that).
      - NateDad 7y ago
        Oh, oops, yeah, I misread "some" as "same". Denoting what contract they obey is just the name, isn't it? T1 and T2 are names of contracts. I guess what you can't do by just using the contract name is say that two arguments must be of the same type. Nevermind.
        msbarnett 7y ago
        > Oh, oops, yeah, I misread "some" as "same". Denoting what contract they obey is just the name, isn't it? T1 and T2 are names of contracts. No, T1 and T2 name two generic types to be used in the body, the question is, where do you specify what contract they fulfill? Eg if we convert an example from the doc to your suggestion: func SetViaStrings(type To, From viaStrings)(s []From) []To { becomes func SetViaStrings(s []’From) []’To { but how are where do you suggest we specify that From and To implement the viaStrings contract? It doesn’t make sense (under this proposal) to replace them with a contract name directly, because the contract in this case takes two type arguments with different expectations of each. You’d need to change the whole proposal such that each contract constrained only a single type, and each function argument could specify potentially a different contract, rather than the current proposal, in which you can only specify one contract that constrains all of the types involved.
jhoechtl 7y ago
Eventually it will morph into Lisp
- higherkinded 7y ago
  Not sure why becoming way more simple and readable is a bad thing.
  - AlexeySoshin 7y ago
    (since(when(lisp(is(readable)))))
utahcon 7y ago
Honestly asking what "generics" offers over passing and handling interface{}. func myBlah(thing interface{}){ switch thing.(type) { case int: // handle my int case string: // handle my string default: // default handling } }
- cjslep 7y ago
  See [0] which is a code generated piece of the ActivityStreams spec. As it is RDF based, it is an open ended set. Not worth doing by hand. [0] https://github.com/go-fed/activity/blob/master/streams/gen_type_resolver.go https://github.com/go-fed/activity/blob/master/streams/gen_t...

by cjslep 7y ago

eternalban 7y ago

And it is basically notation noise. The idea is to inform the compiler as to which type names are generic. // proposed func Print2(type T1, T2)(s1 []T1, s2 []T2) { ... } vs // less noise func Print2(s1 []'T1, s2 []'T2) { ... } This proposal does -not- seem to be informed by the same 'outer space' mindset that gave us the Go language. A reminder that mere capitalization in Go language informs visibility and access. Beyond mere syntax issues, the semantics of generics itself is adding huge complexity to what is a very capable and accessible 80% language.

Insanity 7y ago
I really don't think generics (or contracts) will benefit the language. Most people who miss it are just missing the collection frameworks from Java/C#, and there are solutions to this anyway. (go:generate being one of them if you really need collections for X types). I did miss generics when I first started writing Go, but after doing so for about a year at work and 2 years before that, I don't find me missing them at all.
- JyB 7y ago
  I have the exact same feeling. I was using generics extensively in C# particularly. I don't miss them at all after having spent a lot of time working with and understanding Go. I can't help but feel it will just make the language far less attractive in the long run.
  - Insanity 7y ago
    Yeah I believe so as well. All languages having the same features would also be a downside. Just make a choice and stand by it. (Like Haskell, they are not pressured into doing things just because Java does so).
    - danieldk 7y ago
      Like Haskell, they are not pressured into doing things just because Java does so I do not mean this as a criticism of Haskell, but Haskell has a lot of GHC-specific language extensions: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html https://downloads.haskell.org/~ghc/latest/docs/html/users_gu... I am not sure it qualifies as making a choice and standing by it.
- eternalban 7y ago
  I agree. I am not missing generics at all. It's a pain once is a while but it passes. But addressing that minor downside in no way in my mind justifies destroying what actually makes Go an effective language.
ithkuil 7y ago
interesting > func Print2(s1 []'T1, s2 []'T2) { ... } where would you add the claim that T1 and T2 must obey some named "contract"?
- NateDad 7y ago
  They'd both be T1 in that case. T1 T2 means they're different contracts.
  - coldtea 7y ago
    I don't think parent implied that they should obey the same construct. He asked where you'd denote the contracts each type much obey (e.g. the focus being: in which place, assuming, I guess, that you intent to stray from the current proposal of defining that).
    - NateDad 7y ago
      Oh, oops, yeah, I misread "some" as "same". Denoting what contract they obey is just the name, isn't it? T1 and T2 are names of contracts. I guess what you can't do by just using the contract name is say that two arguments must be of the same type. Nevermind.
      - msbarnett 7y ago
        > Oh, oops, yeah, I misread "some" as "same". Denoting what contract they obey is just the name, isn't it? T1 and T2 are names of contracts. No, T1 and T2 name two generic types to be used in the body, the question is, where do you specify what contract they fulfill? Eg if we convert an example from the doc to your suggestion: func SetViaStrings(type To, From viaStrings)(s []From) []To { becomes func SetViaStrings(s []’From) []’To { but how are where do you suggest we specify that From and To implement the viaStrings contract? It doesn’t make sense (under this proposal) to replace them with a contract name directly, because the contract in this case takes two type arguments with different expectations of each. You’d need to change the whole proposal such that each contract constrained only a single type, and each function argument could specify potentially a different contract, rather than the current proposal, in which you can only specify one contract that constrains all of the types involved.

jhoechtl 7y ago

Eventually it will morph into Lisp

higherkinded 7y ago
Not sure why becoming way more simple and readable is a bad thing.
- AlexeySoshin 7y ago
  (since(when(lisp(is(readable)))))

utahcon 7y ago

Honestly asking what "generics" offers over passing and handling interface{}. func myBlah(thing interface{}){ switch thing.(type) { case int: // handle my int case string: // handle my string default: // default handling } }

cjslep 7y ago
See [0] which is a code generated piece of the ActivityStreams spec. As it is RDF based, it is an open ended set. Not worth doing by hand. [0] https://github.com/go-fed/activity/blob/master/streams/gen_type_resolver.go https://github.com/go-fed/activity/blob/master/streams/gen_t...