> Both Elm and Standard ML have additional type constraints for numbers and comparable types that aren't implemented in terms of a user-definable type constraint like Haskell's typeclasses.
That's not really true. Standard ML has overloaded operators for int/real, but you cannot write a polymorphic function over any kind of number without using the module system. This is a key distinction. Standard ML does have a notion of 'equivalence type variables', which is frequently seen as a wart (since you often get an equality definition you might not be interested in). Standard ML has nothing for 'comparable' types (except, again, through the module system).
Offhand, I can't really think of any other language that uses builtin type classes in the style of Elm.
I guess Go is the only language which comes close, which has map and array/slice which cannot be implemented in the language itself. Though it's the lack of generics, not ad-hoc polymorphism which is Go's lack.
Then again, it wouldn't surprise me if of all the languages you've thought about, Elm is the only one which hasn't reached 1.0 yet.
I think Elm will get some mechanism of ad-hoc polymorphism before it reaches 1.0, but I don't think it will be type classes. Though, I have been wrong before.
That's not really true. Standard ML has overloaded operators for int/real, but you cannot write a polymorphic function over any kind of number without using the module system. This is a key distinction. Standard ML does have a notion of 'equivalence type variables', which is frequently seen as a wart (since you often get an equality definition you might not be interested in). Standard ML has nothing for 'comparable' types (except, again, through the module system).
Offhand, I can't really think of any other language that uses builtin type classes in the style of Elm.