"All of those should be generic, but aren't."

I think even more damning then "these should be generic" is that there should be more of them. The real problem is the lack of generics inhibits the introduction of more data structures because they are hard to use.

It is true that arrays and maps/hashes take you a long way, but there's a lot of other useful data structures in the world. And despite the fact they may look easy at first, data structure code tends to be notoriously difficult to write both correctly and with high performance.

> All of those should be generic, but aren't.

They aren't because the prevailing attitude is "what do you need generics for? Just do a cast!"

The issue is the Go developers are unwilling to consider generics until someone can come up with a problem that absolutely, positively cannot be solved without generics. And of course there isn't one.

I mean, having to cast after every single call to heap is a problem.

Go is turing complete already, so all problems are already able to be solved. :)

Agree- having map, filter, reduce with strong type guarantees will be a huge boon. Imagine being able to map over a collection and the code hints will understand the new output types in the chain. This is something you cannot have when your higher order ops are all typed to Interface {}.

Unfortunately, Go is a language whose original creator is of the opinion that map/filter/reduce are just ways to make your program "fit on one line"[1], and that you should just use a for loop[2].

[1]: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC... [2]: https://github.com/robpike/filter

I'm not sure why this is being downvoted. These are perfect examples of where generics would make a genuine improvement.

The sync.Map case for generics is a perfect example. Thanks for bringing it up.