Generics themselves maybe not. Generic methods probably yes. What people want generic methods for is to do deeply nested call chains that were never typical of Go. And if you have deeply nested calls you'll need some way to deal with errors in deeply nested calls, and then a short function syntax to pass to behavior inside those deeply nested calls. Give it a few years and everyone will be writing the same functional slop in Go that they are writing in every other language.
> What people want generic methods for is to do deeply nested call chains
I don't see that as the only use of generic methods.
The example in the article is a "Map" method that transforms e.g. a List[A] to a List[B], by taking a function that takes an A and returns a B. To be able to transform a list like that is a useful operation.
It was possible to do the same with a global function like MapList but the syntax is nicer if you use methods. You don't need the type in the name (function MapList vs method Map) and it is an operation on the List after all so list.Map(..) is nicer than MapList(list, ..).
The generic methods that have been added are essentially just syntax sugar. You can now use method syntax in cases where you could equivalently define a function. They’re not the fundamental extension to the type system that some people have been asking for (and probably will never get, because there’d be no reasonable way to implement it).
Not here against Generic methods, but I feel the Go team is in a mid-age crisis where they lack of new things to do to prove themselves. See their iterators mini-drama not long ago?
I feel the sumtype/emum/routine demanders should yell a little harder so Go team can find their purpose again.
> generics were a slippery slope. give it a decade and Go will be indistinguishable from c++
Lib boost will have conquered every language by then!!! :D
Jokes aside, generics are unusable in a lot of languages due to their syntax choices. In Go we kinda have the problem that there's no real templating and no real macros, so they're even harder to use.
But I agree somewhat, generics feels to me like an anti pattern in Go.
Also, the way the Go core/stdlib is written, it makes generics so unnecessarily painful to debug. Why they decided to have definitions like "~C" or "~[]S" is beyond me. No human knows what the resulting compile time error means. They should have named these things "Comparable" or "Slicable" or whatever is more expressive. Just stop with this stupid single letter shit.
Generics themselves maybe not. Generic methods probably yes. What people want generic methods for is to do deeply nested call chains that were never typical of Go. And if you have deeply nested calls you'll need some way to deal with errors in deeply nested calls, and then a short function syntax to pass to behavior inside those deeply nested calls. Give it a few years and everyone will be writing the same functional slop in Go that they are writing in every other language.
> What people want generic methods for is to do deeply nested call chains
I don't see that as the only use of generic methods.
The example in the article is a "Map" method that transforms e.g. a List[A] to a List[B], by taking a function that takes an A and returns a B. To be able to transform a list like that is a useful operation.
It was possible to do the same with a global function like MapList but the syntax is nicer if you use methods. You don't need the type in the name (function MapList vs method Map) and it is an operation on the List after all so list.Map(..) is nicer than MapList(list, ..).
The generic methods that have been added are essentially just syntax sugar. You can now use method syntax in cases where you could equivalently define a function. They’re not the fundamental extension to the type system that some people have been asking for (and probably will never get, because there’d be no reasonable way to implement it).
Not here against Generic methods, but I feel the Go team is in a mid-age crisis where they lack of new things to do to prove themselves. See their iterators mini-drama not long ago?
I feel the sumtype/emum/routine demanders should yell a little harder so Go team can find their purpose again.
> generics were a slippery slope. give it a decade and Go will be indistinguishable from c++
Lib boost will have conquered every language by then!!! :D
Jokes aside, generics are unusable in a lot of languages due to their syntax choices. In Go we kinda have the problem that there's no real templating and no real macros, so they're even harder to use.
But I agree somewhat, generics feels to me like an anti pattern in Go.
Also, the way the Go core/stdlib is written, it makes generics so unnecessarily painful to debug. Why they decided to have definitions like "~C" or "~[]S" is beyond me. No human knows what the resulting compile time error means. They should have named these things "Comparable" or "Slicable" or whatever is more expressive. Just stop with this stupid single letter shit.