Hacker News Reader

Comment by fsdjkflsjfsoij | Hacker News Reader

> given it's poor performance for things like functional programming, makes it surprisingly of little use.

In most cases it doesn't have "poor" performance and if you're going for optimal performance you are almost never going to be using generic data structures anyways because there's almost always type specific optimizations that can be done.

The intended use case is, and always has been, decently performing type safe data structures and Go generics are sufficient in most cases for that. Go is never going to be a functional programming language.

View on HN

I think the parent believes that code which allocates a lot and puts function calls in tight loops is an end unto itself, and he’s quite correct that Go isn’t going to perform well in those cases. Go’s memory management chooses expensive allocations and low latency over cheap allocations and high latency, which is appropriate because idiomatic Go doesn’t allocate often but as with anything, people who want to deviate from Go’s opinions experience a lot of friction and express frustration by characterizing Go as a bad language or in this case “a drawer full of dull knives”. One wonders if the parent gets frustrated that his blender is no good for driving nails or that his sink is too small to bathe in.

Monomorphization is one of the ways generics are implemented in other languages and it definitely allows for type-specific optimizations.

I imagine there's a rationale for not implementing generics this way, like keeping binaries small, but it seems like a weird tradeoff considering it increases overall memory consumption and decreases performance quite a lot...

If I understood the implementation correctly, as long as you use value types instead of pointer/interface types for your generic type parameters, you'll basically get monomorphization.

I don’t think this is true. If your value types use methods in the generic code, I think you get dictionaries regardless (maybe Go doesn’t emit dictionaries if there is exactly one implementation for a gcshape?). Value types just make it more likely that you’ll have distinct gcshapes, but I’m pretty sure you’ll still get dictionaries. The only way you don’t is if you have a pure container (no calling methods on type parameters). That said, I believe there’s an undocumented flag to force full monomorphization, but it’s probably not stable.

If it was up to me I would have gone with full monomorphization because I don't care about binary size or compilation time quite as much as the current Go developers. However, the decrease in performance of the current implementation is being vastly overstated because people read a single article. It's not going to be even close to a bottleneck in all but the most extreme performance demanding applications and those applications probably shouldn't be using a garbage collected language to begin with.

There are two possible extremes for the implementation of generics: full monomorphization on one side, and dictionaries on the other side. Both have serious drawbacks: monomorphization is faster, but produces bloat, and dictionaries are slower but don't produce bloat. Go chose to combine the two for a middle ground. It's a bit more complicated to implement than just monomorphization or just dictionaries, but it provides a nice balance.

I agree with everything you wrote but would add that it's even more complicated because there are cases, albeit rare in my experience, where full monomorphization produces slower code due to cache misses. I believe std::format in C++ is generally considered an example of this https://youtu.be/zssTF1uhxtM?t=2021

I think it’s about keeping binaries small and compile times fast. I suspect they’ll monomorphize more in the future, but they want to proceed incrementally, which seems reasonable to me.

Reply on news.ycombinator.com