Live data from Hacker News

Go generics are not bad

lemire.me

61–70 of 305 posts

Re: Go generics are not bad

#62

This 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…

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Took me five minutes, not four days…

Re: Go generics are not bad

#63
post #33

Earlier 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”

You're right, and foo x = foo x also qualifies as 'a -> 'a. The only function that always terminates is the identity function, then.

Re: Go generics are not bad

#64

The site gives assembly code of the inner loop, but isn't the problem that there is additional overhead on the calling of generic functions?

AFAIU, as compared to pure monomorphization, yes, sometimes the model imposes runtime indirection. This is particularly the case for methods. However, for simple yet common cases, such as functions taking []T, the model permits inlining into the caller.

Re: Go generics are not bad

#65

The site gives assembly code of the inner loop, but isn't the problem that there is additional overhead on the calling of generic functions?

I believe Lemire's point is that the compiler is still able to inline the function despite the generic definition, so at least in this somewhat narrow case generics are a zero-cost abstraction.

Re: Go generics are not bad

#66
post #51

proper 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

Julia gives you the same (but dynamic rather than static), but without the awful syntax.

Re: Go generics are not bad

#67
post #24

Earlier 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).

really? Is Go that bad? Write a server that does communication or emulate select in Go in other languages. Go is really effective at writing things fast at the same time that it has value types and can scale not only in I/O but also in multi-core in a way that is easier than anything I saw before. I am a mainly C++ person but I must admit that the cost/investment ratio in Go is really good for writing server-side stuff.

Re: Go generics are not bad

#68

This 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…

The sum example is simple, but very often have I seen people write general solutions for business logic or whatnot that you can't just get from a 3rd party package, when it wasn't at all clear that's needed. I have done this myself too.

Re: Go generics are not bad

#69
post #51

proper 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

.NET 7 improves this with static abstract members in interfaces and generic math.

https://github.com/dotnet/csharplang/issues/4436 https://devblogs.microsoft.com/dotnet/dotnet-7-generic-math/

Re: Go generics are not bad

#70

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.

Well, it means you can't have generic methods in an interface.
Post reply on HN