All the ML and functional languages don’t seem to have this problem, and a lot of them have Type Systems that are far more sophisticated and capable that go’s.
SML actually has a very simple, unsophisticated type system that isn't anywhere near as expressive as generics in most other languages (Java, C#, Go, etc.).
In SML, there's no way to define a generic hash table that works with any type that implements a hashing operation and uses that hash function automatically. Type parameters are entirely opaque types that you can't really do anything with. To make a generic hash table, the user has to explicitly pass in a hash function each time they create it.
In other languages, you can place a bound on the type parameter that defines what operations are supported and then the operations are found (either at runtime or monomorphization time) based on the type argument.
If you don't have bounds, lots of things get easier for the language designer. But lots of things get much more tedious for the language user. It's probably not a coincidence that every language newer than ML with parametric polymorphism has some sort of bound/trait/constraint/type class thing. But bounds are where most of the complexity comes from.
I do agree SML's type system feels elegant and useful at first, and becomes suddenly quite limiting when attempting the kind of domain modeling or library level genericity you'd do in e.g Java.
On the other hand, isn't the hashmap use case you mention addressed with the module system and functors ? Like the set abstraction described in this SO answer [0].
Wondering where my understanding of your message or SML fall short.
