This is like the most cherry-picked example that could've been chosen. Java can't do this because the primitive types are not objects. Mentioning the performance of this is hilarious because 1. it's Daniel Lemire, he should know better and 2. the performance of pretty much every other thing that uses generics is terrible because of gcshapes being passed everywhere and 3. Java literally has a JIT to make generics fast. And bear in mind I don't even like Java generics that much, it's just that Go does even worse. (But still better than when it didn't have it at all, I guess…)
Go generics are not bad
11–20 of 305 posts
Re: Go generics are not bad
#12I think Go's generics are reasonable, but not quite powerful enough to scale. It's all well and good to generalize basic containers and functions (good, in fact), but I wish the language was better at inferring types. I'm sure this is something that will improve with time, but a bit after generics were released, I tried to build a type-safe language evaluator in Go using generics and found them lacking the kind of ty…
I haven't looked into Go's actual implementation but isn't this kind of downcasted better suited for interfaces. Your code, as is, wouldn't translate to something like Rust which uses monomorphization; you are doing a runtime "inspection" of the types. This looks more in the domain of duck-typing than something that generics handles.
Here's a writeup exploring this very topic, and showing how Go's generics will currently give worse performance than just using an interface.
https://planetscale.com/blog/generics-can-make-your-go-code-...
Re: Go generics are not bad
#13This 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…
This was just discussed here in another front page post “Why DRY is the most over-rated programming principle” https://news.ycombinator.com/item?id=32010699
Re: Go generics are not bad
#14This 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…
> What's this called?
The blub paradox https://wiki.c2.com/?BlubParadox
Re: Go generics are not bad
#15This is like the most cherry-picked example that could've been chosen. Java can't do this because the primitive types are not objects. Mentioning the performance of this is hilarious because 1. it's Daniel Lemire, he should know better and 2. the performance of pretty much every other thing that uses generics is terrible because of gcshapes being passed everywhere and 3. Java literally has a JIT to make generics fast…
How can Go does it even worse that Java where generics implementation is the worse of all modern language with type erasure.
Java is way worse than Go on that aspect.
Re: Go generics are not bad
#16This is like the most cherry-picked example that could've been chosen. Java can't do this because the primitive types are not objects. Mentioning the performance of this is hilarious because 1. it's Daniel Lemire, he should know better and 2. the performance of pretty much every other thing that uses generics is terrible because of gcshapes being passed everywhere and 3. Java literally has a JIT to make generics fast…
[deleted]
Re: Go generics are not bad
#17This is like the most cherry-picked example that could've been chosen. Java can't do this because the primitive types are not objects. Mentioning the performance of this is hilarious because 1. it's Daniel Lemire, he should know better and 2. the performance of pretty much every other thing that uses generics is terrible because of gcshapes being passed everywhere and 3. Java literally has a JIT to make generics fast…
Most things first exist, then exist and are good. We've seen the start of Go generics existing, but we haven't seen them be as good or as fast as they will ever be.
Five years from now, Go will still exist. The implementation of generics in that future version of Go is likely to be much faster and better than what we currently have.
Put a different way, "Generics are slow in Go v1.18"
Re: Go generics are not bad
#18aha, so Go has some kind of generics now, so since it has become a real programming language I might actually give it a spin! /s
Never understoon why Generics where subject of a holywar in go community. It's an important nad basic feature these days
Re: Go generics are not bad
#19This is like the most cherry-picked example that could've been chosen. Java can't do this because the primitive types are not objects. Mentioning the performance of this is hilarious because 1. it's Daniel Lemire, he should know better and 2. the performance of pretty much every other thing that uses generics is terrible because of gcshapes being passed everywhere and 3. Java literally has a JIT to make generics fast…
How can Go does it even worse that Java where generics implementation is the worse of all modern language with type erasure. Java is way worse than Go on that aspect.
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.
Re: Go generics are not bad
#20This is like the most cherry-picked example that could've been chosen. Java can't do this because the primitive types are not objects. Mentioning the performance of this is hilarious because 1. it's Daniel Lemire, he should know better and 2. the performance of pretty much every other thing that uses generics is terrible because of gcshapes being passed everywhere and 3. Java literally has a JIT to make generics fast…
Most things first exist, then exist and are good. We've seen the start of Go generics existing, but we haven't seen them be as good or as fast as they will ever be. Five years from now, Go will still exist. The implementation of generics in that future version of Go is likely to be much faster and better than what we currently have. Put a different way, "Generics are slow in Go v1.18"
Someone will read a blog post about slow generics, ignore how it evolves, and tell every coworker for then next 10 years that go generics are slow