[masklinn]

And even if you assert that the use cases for generic structures are limited (which is debatable but why not) there's definitely something to be said for generic functions over existing generic types e.g. currently if you want to build utility methods over slices or maps (like… set operations because everybody uses maps but maps don't have set operations) you have to pick between:

* manually instantiating (handrolling) every version, possibly duplicating it if you don't realise somebody else did

* same except using codegen, which is easier to maintain but has more semantic overhead (now you need to add codegen to the project and there's an extra build step to consider)

* or manually type-erase and cast back, risking type safety and most likely performances

A flagrant example from the stdlib is the `sort` package with its weird and alien interface (and Interface), inability to use key functions, and which can only work in-place.

Talking about in-place but circling back to generic structures / collections, a big use-case I expect to see for generics would be type-safe (immutable) concurrent collections e.g. HAMT, RRB, …. Current Go significantly limits the ability to "share by communicating" (as well as safely "communicate by sharing") as there's no good way to build and make any sort of high-quality concurrent collection available, whether persistent or mutable.