> А заодно бы ad-hoc polymorphism завезти, а то
> стыдно как-то в 2020 году использовать разные операторы сложения для int
> и float.

Ну уж что что, а полиморфизм в ML есть из коробки (система типов ХМ же):
- fun f x y = (x, y);
val f = fn : 'a -> 'b -> 'a * 'b

и хоть ты int туда передавай, хоть real - все одно.
Кстати, я очень удивился, когда увидел type variable. До ML я познакомился с Rust и теперь постоянно смотрю: а что же в Rust взяли из ML. Обозначение 'a, например, взяли, но поменяли семантику: теперь это не type variable, а life time. Оператор match - это один в один case из ML и т.д.
Чего не хватает Расту, так это формального определения и доказанной корректности. Хотя систему типов уже вроде верифицировали и RustBelt чего-то там ковыряют дальше. Доковыряли бы до конца - цены б Расту не было, идея с ownership мне прям очень нравится.

А вот в модном нынче Go, например, полиморфизма как раз нет - надо определять вагон и маленькую тележку функций для каждого возможного типа параметров. Или писать одну функцию, принимающую interface{}, а в ней - длиннющий type case. Ну не костыль ли, а?