41–50 of 305 posts
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…
I guess I’ll wait until the full review then
Earlier quoted context omitted.
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
The title says Go generics are not bad, and then in less than a page this guy only compared one use case with Java's generics. I'd expect a CS professor to be able to add a little more rigor in a blog post but I guess everyone is losing patience to read and write these days, even for the supposedly erudite.
Someone submitted and people liked it, and it ends up in HN front page.
All I am saying, please don't put pressure on random blog writers. You can criticize the content without saying "CS professor can be more rigor".
Earlier quoted context omitted.
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.
Type erasure is interesting. It turns out that not doing type erasure (combined with instanceOf-like things, like pattern matches on type parameters) breaks parametricity. Parametricity is a very powerful reasoning tool. Of course, type erasure isn't the actual culprit in that case, but once you don't do it, it gets very tempting to allow pattern matching on type parameters...
Earlier quoted context omitted.
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.
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.
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…
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.
interface Numeric {
T zero();
T add(T a, T b);
}
static T sum(Numeric n, T[] v) {
T summer = n.zero();
for (int k = 0; k Earlier 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.
But for some `foo.Add(bar)` can be considered nicer than `AddFoo(foo, bar)` or `foopkg.Add(foo, bar)`. The semantic differences are mostly in in an aesthetic/stylistic/personal preferences realm, so it's hard to argue for or against it.