Note that, at least in its current form, the native concurrent map type uses interface{} for all keys and values, and therefore offers no type safety:

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

See also: https://github.com/golang/go/issues/18177

All of Go's built-in pseudo-generic types (e.g. maps) require special support from the parser. I'm not sure if they plan on doing that for sync.Map as well, but this is clearly an area that could benefit from generics.

I guess the performance issue has something to do with some missing optimizations. Hopefully it will get better.

Edit: Also https://github.com/golang/go/issues/19361

For (1), for curiosity sake, I tried benchmarking the cuckoo.go file you posted. I'm curious if these numbers are in line with what you found. The first test I did was a Rand test, Putting 10,000 random string values under random string keys, then Getting the same 10,000 keys, then Getting 5000 more random keys. The first line below uses default code you posted, which uses

    type keytype string
    type valuetype string

    BenchmarkRandInsert-8                                100      13474408 ns/op
    BenchmarkStringStringRandInsert-8                    100      13585071 ns/op
    BenchmarkStringVoidStringRandInsert-8                100      14126666 ns/op

If I use uint32 for value instead, I get:

    BenchmarkStringIntRandInsert-8                	     200	   9431584 ns/op
    BenchmarkStringVoidIntRandInsert-8            	     100	  10485785 ns/op

I ran a sequential-insert test as well, with keys and values generated sequentially instead of randomly. The results are much the same, though the cost of casting to/from interface{} seems to get mostly lost in the noise.

    BenchmarkSequentialInsert-8                          100      12185272 ns/op
    BenchmarkStringStringSequentialInsert-8              100      12233946 ns/op
    BenchmarkStringVoidStringSequentialInsert-8          100      12543980 ns/op
    BenchmarkStringIntSequentialInsert-8                 200       8823747 ns/op
    BenchmarkStringVoidIntSequentialInsert-8             200       8709242 ns/op

I didn't find the interface{} casting in any of the above code too horribly "gross", just a bit ugly, but that's entirely subjective. Yes, all of the cuckoo versions seemed about 30% slower than the corresponding builtin map type, but my benchmark numbers don't show if that is the price of boxing, of supporting concurrency, or maybe function call overhead, or something else. I'm guessing you did more detailed benchmarks that point to the source of the slowdown.

One last comment: keytype and valuetype really need to be exported, don't they? I wasn't able to use the library without changing them to exported symbols.

Overloading is usually not a "generics" concern in most mainstream languages[1]. If you do a "type class"/"Rust-style-traits" (or even multiclasses) thing then it sort of naturally takes a front seat. Incidentally, Haskell fucked this one up horribly in some respects, see the "Num" type class.

Of course, e.g. Java could theoretically add an interface called Addable to complement Comparable which would sort-of allow generic "+", but they've chosen to not opt for that. The fact that the "first parameter" is privileged is also a bit of a detriment to such syntax conveniences. (I can expand on this, but it's bascially because that for "X op Y" and "Y op X" to work, they both need to know of each other. This problem can be solved by type classes, but cannot be solved by overloading, AFAIK.)

[1] If you do have overloading from the outset (like Java, IIRC), then you're constrained because you need to be able to "pick the most specific overload" in a "generic" context.