I agree from a technical POV, but there is a social reason (network effect): Swift has Apple-backing, OCaml is not currently supported by any of the big, influential software companies. OCaml's main backer now is Jane Street who do a lot, but is too small, and Facebook's support (via ReasonML) is too half-hearted to be compelling. As a former OCaml programmer, I would not currently bank a career or startup on OCaml. Indeed I've been doing OCaml programming over the last few weeks (and seen the shortcomings of OCaml's current library eco-system vis-a-vis more mainstream languages) in order to interface with a big existing OCaml development, and they told me they decided to move to Rust for all future new developments.

I say this with a heavy heart, as somebody who spent his first decade as a programmer with OCaml.

Interestingly, even in Feb 2021, there is no compelling mainstream alternative to OCaml (in the sense that e.g. Jane Street are using OCaml): Haskell's being lazy, Java/Scala etc as well as F#/C# being JIT'ed make performance predictability difficult. Rust does not have this problem, but for many tasks where software engineering agility is a more important consideration that extreme performance (which might be most in-house business software?), a GC'ed language would appear to be more suitable.

(No language war please ...)

> ...F#/C# being JIT'ed...

Nope, NGEN exists since .NET 1.0, .NET Native since Windows 8, Mono aot since ages, and then there are the third party tooling like IL2CPP.

Thanks. I was not aware of this, since I've not worked on a Microsoft stack for a long time. Are those F# AOT compilers mature and support all features, including libraries? In this case F# would be a viable alternative to OCaml for Jane-Street-like tasks.

Yes, but GC is usually seen as the major .NET performance concern not AOT vs. JIT, which may be faster in some instances.

You can also use Haskell with the Strict pragma enabled for your own code if laziness is a concern.