- Single Core Speed (Ocaml is fast)
- native compilation without requiring some installed runtime
- Polymorphic Variants (Last I read, to be used only when regular variants are not sufficient)
- Modules and Functors (there's a proof of principle for F# supporting these)
- GADTs (allow for richer more expressive types, much more flexibility than regular algebraic data types)
- camlp4
- more pervasive structural typing, higher kinded types...type system is not weighted down by a foreign runtime
Where F# is better:
- better support for not-sequential programming in all its forms: actors with lightweight threads, parallel, async, gpu (many production ready choices), reducers (and Go style channels if they accept joinads)
- Active Patterns are a dark horse
- Type Providers are curious. They seem like dumbed down metaprogramming at first but it's one of those cases where constraints benefit creativity. Although you could certainly do what they provide (and more easily at times) with metaprogramming, I've never seen metaprogramming used that way before. And especially with the proliferation of APIs, stuff like json inference makes going to a language without them like going from 3 monitors to one.
- Units of Measure
- More libraries and Better cross platform support via Xamarin and unity3d
- #light. F# syntax is a tiny bit cleaner and surprisingly close to Python at times.
- Computation expressions/do notation are not quite monads and can be more flexible. Tomas Petricek argues the case here: http://tomasp.net/blog/2013/computation-zoo-padl/
Why the above do not matter: The MLs tend to be more pragmatically focused than other functional languages and espouse using as little fancy code as possible. The core of both languages are the same, so much of the time and ignoring library choices, you won't be seeing many differences between F# and OCaml. It's more like Portuguese vs Spanish than English vs German.