[dehrmann]

And honestly, 9 times out of 10, I'm better off rebuilding the list because vectors have lower memory overhead and the memory is contiguous. But that one time... I've also been spoiled by Java's very rich set of collections.

[josephg]

Linked lists aren't the best example because they're almost never the right tool. But in the last month alone on a rust project I'm working on I've used:

- Option, Result, and other stuff from the standard library.

- My own B-Tree implementation w/ domain specific enhancements, in about 4 different contexts

- A heap based priority queue

- A custom 2 level vec, to support arbitrary insert & delete without shuffling elements around. (This turned out to be faster than my b-tree but less memory efficient.)

- Several different custom iterators, and iterator combinators. Eg, I have an iterator over some data which gets computed on demand. I have an iterator which consumes and run-length encodes each item in another iterator. And so on.

All of this stuff has generic type parameters everywhere. The b-tree is generic not just over the stored data, but also over the way its index works. I can specialize it to do a bunch of different tricks by just changing a type parameter.

All of this code is fancy and hence difficult to read for the uninitiated. And that isn't the Go way. But there's a big, valuable middle ground here. I'm glad Go is adding some options to let people lean a little bit into cleverer code when it becomes appropriate for the problem domain. Emulating generics with interface{} seems worse than just adding generics into the language.

[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.