[eschneider]

This all looks like reasonable implementation behavior which will give optimal runtime performance in most "common" cases. If one really wants or needs a map that'll free memory as it shrinks (and sure, for some folks, that'd be super useful) one's always free to just implement your own.

[eptcyka]

Go doesn't really allow you to create a hashmap with the same generic possibilities as the built in one.

[ironick09]

Why is it? Or rather what limitations are there to enforced by go compiler that won’t allow someone to implement their own hash map that can free memory with the same generic possibilities, even with the recent introduction of generics?

[eptcyka]

Seems like I was wrong about my assumptions about Go's generics - it does seem like they're specialized at build time and it is possible to operate over generic values rather than fat pointers. So it is possible to implement a fully featured hash map without extra pointer hopping now. I stand corrected.

[jimbokun]

Is that still true with the support Go added for generics?

[morelisp]

You probably won't be able to match the built-in's performance without a similarly large surface area of unsafe usage. And Go's maintainers won't maintain your unsafe code for you as they do the default, nor consider the impact of other language changes on your micro-optimizations.

https://github.com/golang/go/blob/master/src/runtime/map.go

You also won't have `for k, v := range` iteration, but that is also likely being addressed within the next few versions.

But - no, there's not really any major ergonomic issues to basic lookups given generics these days.