"Something that is simple may take longer to write and might be more verbose" -- from the article.
In a simple language, there should not be functions that do exactly what you want to do; that would be a sign of the language being complex and featureful, which are enemies of simple.
(and yes, this is a bit tongue-in-cheek)
An alternative would be to use [16]byte as your map keys and then subslice the array for net.IP.
See http://blog.golang.org/go-slices-usage-and-internals to get a basic understanding
So exactly why are they not suitable for equality? Even that article starts with "Slices are analogous to arrays in other languages". Please elaborate on this basic thing.
For slices? Also element-wise? Even with different capacities? If the refer to the same window in the underlying array? Is there a need to copy the slice for inserting it to the map? Probably yes, because otherwise you could mutate the key from outside. But then it would be inconsistent to assignment (slices are reference types).
I have no idea how this could be done concisely.
As far as the whole ownership issue, that's a bit more than just ==, isn't it? Equality was the only thing I was questioning.
Lack of generic access to data structures is one of their bigger fails.
However, they don't see it that way. One point of Go was to prevent needing to describe things before being able to compile it. Most things that people regard as "failures" in Go were deliberate choices to enable large codebases.