> So you don't understand what's happening here. They are not "hashing a structure", they are digging into internal implementation to reuse code that runtime uses to hash the structure.
Because Go does not expose the builtin hash function.
> is not doing that.
It's doing that without the feature existing.
> Also Go is not object oriented language
Which is not actually relevant, it clearly knows about "comparable" (which it also considers to mean "hashable"). It just refuses to expose that information.
> so having type.hash() like Java or Python would make no sense.
Are you wilfully picking at the tree's bark in order to avoid considering the forest for a single second?
> Whether that's a good or bad call is another discussion but writing generic Hash[T] is few lines of code and would be just encoding/gob into hash of your choosing.
And lose the benefit of the way the entire ecosystem works.
On the plus side, it would let you have keys with bespoke equality and hashing semantics, but that's clearly not what TFA is looking for.
It also can't be combined with go's own hashable because you can't involve either "comparable" or an interface with methods in a union, so there is no way to accept a "comparable|Hash" in order to leverage both.
And obviously by doing so you'd open the door to them being inconsistent. Which is also the point of using Go's own concept of hashability.