As someone who really enjoys OCAML, it has a variety of issues that prevent it from becoming popular (though I'm hopeful for reasonML).

No multicore

Standard library has... issues

No community consensus on a common base setup, questions about which library to use for a task often get answers like "well, do you want to use functors or monads? because that will change the library we recommend" which is really not what you want to hear when you're just trying to set up your first server.

Documentation is, in general, bad. Most packages just give a list of function signatures.

The community is small, academic, and often French.

Modern OCaml (4.06+) is not that bad, but yeah, lack of proper parallelism and bad Windows support (without hacks like MinGW or Cygwin) is what still hurts. Standard library these days is only one - Base, one buildsystem - Dune, Camlp4 is dead, and compiler improved a lot recently (including speed if you enable flambda).

You guys are welcome to D, you may enjoy unboxed floats, guaranteed monomorphization and native threads. Also, 3 backends.

The reference compiler is as free-standing as OCaml's because it too has its own back-end. Its front-end is shared with the other 2 back-ends: feeds the ubiquitous LLVM in LDC, and is included as a supported front-end in GCC since version 9.1.

Anyway, there is no way you'd give up ML-tradition pattern-matching; D doesn't have it.

Well engineering decision are tradeoffs, using D i've never missed pattern-matching and I have used ocaml before.

Honest question: what is so bad about having to create one process per core? If you have lots of data you can use shared memory, so the performance should be similar no?

For shops that really care about highly performant parallel tasks, the difference matters. For people who just want more performance for free it's too much work versus what other languages provide.

If OCAML were already popular I don't think the lack of parallelism would be huge issue, but it's niche, which is a huge downside to any language in a business context. The upsides the language provides in terms of performance, ergonomics, and maintainability need to overcome that downside. All the issues I listed mean that OCAML can't generally pass that bar.

I don't know. Maybe because it is GC-only? It doesn't have custom allocators, so there may be no easy way to map an object to some location in shared memory.

Not the grandparent, but...

OCaml: multicore, standard library situation (which one?) is a mess, adoption. F#: Have to deal with null and lack of ADTs when you interact with .NET (or JS for Fable) standard lib. The tooling situation in F# has been a mess since .NET Core, especially in Linux. Treated as a 2nd class citizen by MS.

Multicore OCaml is actually making promising progress, but I agree that the standard library situation is a little bit unfortunate.

Sadly, that's what I've been hearing for at least 5 years.

I'm using F# tooling in Linux and both VS Code and Jetbrains Rider's IDE's outclass most functional language IDE's at present IMO. It's greatly improved within the last year or so. If you use code most of your app in F# the null factor doesn't really bite you all too often and its not too hard to handle when it does.

I love OCaml, but my biggest pain point is not having something like Cargo. I haven't spent a lot of time with opam since 2.0 came out, so maybe it's better now, but when I used it it felt very much designed around installing packages globally, instead of defining dependencies per-project.

The other issue with the package ecosystem is cross-platform support. While OCaml itself works on windows, opam doesn't (or at least didn't) without a lot of extra work, and it seemed like most packages were designed only for unixish OS's.

There are projects where I've used Rust instead of OCaml, even though I'd have preferred to use OCaml, simply because the infrastructure is so much better and easier to use for Rust.

Esy (https://esy.sh/) has completely solved the first problem, fwiw.

This is a huge step in making OCaml more approachable. I get the feeling that there are quite a few of these modernizations around, but you have to know about them up front in order to hit the happy path. Would be great if there was some sort of "OCaml Happy Path" repo that laid out all of the right tools to use to be successful right off the bat. Sort of on the subject, Reason would be great but last I checked it utterly neglected its native compilation story--it advertised native compilation but every time I ran into an issue the Reason community would tell me that OCaml support was broken and I should use Node. Excited for the improvements to be sure!

Thank you! I'll try it out.

Indeed! For example, it is amazing how small Poly/ML is for a type-inferred multi-threaded language.