To get a comprehensive understanding of the current Go custom generics, please read: https://go101.org/generics/101.html
Go generics are not bad
61–70 of 305 posts
Re: Go generics are not bad
#62This is good to hear. There's something like a cognitive bias that makes me leary of genetics (in any language). Once you have some cross cutting feature, generics or object orientation, or in functional programming, those functions of type 'a->'a, or assembly language address modes, people get bogged down by trying to make everything in their work generic or object oriented or "orthogonal". Lemire's example is relev…
Took me five minutes, not four days…
Re: Go generics are not bad
#63Earlier quoted context omitted.
> those functions of type 'a->'a Polymorphism. But note that there is only one function of type 'a->'a for all 'a, and that's the identity function.
Not quite. This also has the type ‘a -> ‘a: def nitpick(x): throw “foo”
Re: Go generics are not bad
#64The site gives assembly code of the inner loop, but isn't the problem that there is additional overhead on the calling of generic functions?
Re: Go generics are not bad
#65The site gives assembly code of the inner loop, but isn't the problem that there is additional overhead on the calling of generic functions?
Re: Go generics are not bad
#66proper generics would be C++ but it is called templates and could be hardcore.. https://stackoverflow.com/a/498329/729738 .Net generics do have same issues mentioned in the article
Re: Go generics are not bad
#67Earlier quoted context omitted.
> Java can't do this because the primitive types are not objects. So this excuses the awful Java genetic how? "It smells like sewage in the basement because the basement is full of sewage." In addition, generics over primitive/stack/value types (including mathematical operators) is working just fine in the latest iteration of C#.
It doesn't. Picking an area where Java is weak and where Go happens to be decent is the very definition of cherry picking. Go happens to do poorly in almost every other area and Java does meh in many (erasure, unsoundness, etc.) and excellent in others (profile-guided devirtualization).
Re: Go generics are not bad
#68This is good to hear. There's something like a cognitive bias that makes me leary of genetics (in any language). Once you have some cross cutting feature, generics or object orientation, or in functional programming, those functions of type 'a->'a, or assembly language address modes, people get bogged down by trying to make everything in their work generic or object oriented or "orthogonal". Lemire's example is relev…
> They need to sum an array of int. So they spend 4 days getting a function and a generic type that can sum every numerical type, rather than 15 minutes to sum int arrays. More likely they install a 3rd party generic sum function and don't have to write their own at all . Well, in the case of a sum function it's probably only 15 minutes to write to generic version, and there may even be one in the standard library. B…
Re: Go generics are not bad
#69proper generics would be C++ but it is called templates and could be hardcore.. https://stackoverflow.com/a/498329/729738 .Net generics do have same issues mentioned in the article
https://github.com/dotnet/csharplang/issues/4436 https://devblogs.microsoft.com/dotnet/dotnet-7-generic-math/
Re: Go generics are not bad
#70Earlier quoted context omitted.
For example, by not allowing one to create a parametrized method. `func (self SomeNonGenericType) Foo[T any](param T) T` is not allowed, best one can do is `func Foo[T any](self SomeNonGenericType, param T) T`. The reasons are explained here: https://go.googlesource.com/proposal/+/refs/heads/master/des... but the point is, you can have this in Java, but not in Go.
Why not use a free function? That is more flexible. Go isn’t Java, it is not a deadly sin to write free functions. You look at something like the Reader and Writer interfaces and there are very few methods. The Go approach is to put more functionality in free functions such as fmt.Fprintf which allows more code reuse across multiple types. In fact I view the heavy Java use of methods as an anti-pattern.