Hacker News Reader

Comment by jamal-kumar | Hacker News Reader

IMHO the biggest deciding use case for me is whether or not it's more performant than any other possible solution. So far I haven't seen this to be the case in other people's benchmarks. [1]

[1] https://planetscale.com/blog/generics-can-make-your-go-code-...

View on HN

By that metric you're almost always better off writing specialized code all the time and duplicating stuff around a lot.

(In all languages, not just go)

Is that so? It kind of sounds like there's cases to consider where there's actually a performance gain, but in certain use cases in languages with implementations of this feature in a different way... From the article I linked:

"Historically, monomorphization has been the design of choice for implementing Generics in systems languages such as C++, D, or Rust. There are many reasons for this, but it all boils down to trading longer compile times for significant performance gains in the resulting code. When you replace the type placeholders in generic code with their final types before the compiler has performed any optimization passes, you create an exciting universe of optimizations that are essentially impossible when using boxed types. At the very least, you get to de-virtualize function calls and get rid of virtual tables; in the best case scenario, you get to inline code, which in turn enables further optimizations. Inlining code is great. Monomorphization is a total win for systems programming languages: it is, essentially, the only form of polymorphism that has zero runtime overhead, and often it has negative performance overhead. It makes generic code faster.

So, as somebody who works on performance for large Go applications, I admit I was not particularly excited about Generics in Go, really. I was excited about monomorphization, and about the potential for the Go compiler to perform optimizations that it simply can’t do when it’s dealing with interfaces. Cue my disappointment: The Generics implementation in Go 1.18 does not use monomorphization… at least, not quite."

This is only the case* when there is actually something to be gained by specializing the implementation of a data type or function for a given type. In my experience that isn't particularly common.

* Excluding Go's implementation of generics, which are frequently less performant than even vtable dispatch, let alone manually copied implementations.

Almost certainly. It's really only C++ and Rust that monomorphize everything (this is one of the reasons their builds take so long).

That's a strange take considering generics can provide important type safety benefits in many situations. For example, without generics, there's no way to implement the `MapKeys` example from the article unless you want to give up type safety and resort to unsafe casts. The performance impact is likely to be negligible in most code unless you're calling generic functions in a tight loop and you've exhausted every other optimization opportunity and you're in a position that requires such micro-optimization. That's a lot of ifs.

The Planetscale article mentions that byteseq (a constraint that is a string of slice of bytes) was actually faster than string or bytes, which was probably just noise in the benchmarking. In general, between the Planetscale article and this one, the takeaway lesson is “Use generics for data containers and other cases that don’t call constraint methods. If you need to call a method, it will probably end up being slower.” It makes sense if you think about it.

Maybe you shouldn't be using go then

Reply on news.ycombinator.com