The tooling is actually OK, provided you work on Linux. If you work on windows, the tooling is basically telling you to go get Linux.

It doesn’t capture a lot of what many functional programmers consider the essence of FP: the language, and the people who use it, actively encourage mutable state in programs, and the type system is not powerful enough to capture useful abstractions like functors (generalized containers) or monads (generalized patterns of computation).

There are also some specific language design decisions that I don’t like. For example, this code typechecks:

let id : 'a -> 'b = fun x -> x;;

The 'a -> 'b is a type annotation that says “you give me anything of type 'a (a type variable), and I’ll give you back something of type 'b.” That’s complete bogus - that’s not possible. It typechecks because OCaml goes “OK, this is fine as long as 'a and 'b are the same variable,” and then for the rest of the typechecking process, that’s what happens. id actually gets assigned the type 'a -> 'a. In the best case, this is confusing and occasionally useful to do what other languages do with “type holes.” In the worst case, it’s actively wrong. Using different type variables in a type can provide static guarantees that some things cannot mix, and with OCaml that is simply not possible for a declaration like this one. You can do it, but with a lot more boilerplate. Compare that to Haskell, where the right behavior is the default, and you can obtain a type hole just by using a variable name that starts with _.

My graduate work is currently on type error provenance. You know some piece of code has a type error, but where is the actual problem? This is a hard problem that compilers are notoriously bad at answering.