> Function type inference makes code impossible to read.
And the type errors very non-local and therefore hard to understand. The reason is that HM type inference infers types not only in the leaves->roots direction, but also roots->leaves. An expression gets assigned a type based on the context it appears in. It works wonderfully when the program type checks, because e.g. it allows one to write something like "let x = None" in Rust instead of "let x: Option<very long type name> = Option<very long type name>::None;" as long as further uses of x (such as returning it as the value of the enclosing function) clarify its type. However, when a program is during development, you change things here and there, when one variable binding (such as a function definition), which wasn't explicitly typed, appears in at least two places which require this variable to have conflicting types, then almost certainly the error is going to be generated for a line that you as a human see completely disconnected from where the error actually is. Maybe it's in the function definition, maybe it's in one of its uses. And those things can be further obscured by several indirections of intermediate functions with successfully inferred types.
And the type errors very non-local and therefore hard to understand. The reason is that HM type inference infers types not only in the leaves->roots direction, but also roots->leaves. An expression gets assigned a type based on the context it appears in. It works wonderfully when the program type checks, because e.g. it allows one to write something like "let x = None" in Rust instead of "let x: Option<very long type name> = Option<very long type name>::None;" as long as further uses of x (such as returning it as the value of the enclosing function) clarify its type. However, when a program is during development, you change things here and there, when one variable binding (such as a function definition), which wasn't explicitly typed, appears in at least two places which require this variable to have conflicting types, then almost certainly the error is going to be generated for a line that you as a human see completely disconnected from where the error actually is. Maybe it's in the function definition, maybe it's in one of its uses. And those things can be further obscured by several indirections of intermediate functions with successfully inferred types.