I feel like on paper, at least, OCaml ticks all the boxes on my programming language wishlist: non-nullability, ADTs, type inference, compiles to binary. A lot like rust but a little higher level. But I've never really had a go at it. I'm sort of reluctant to sink time in it if there's not a future, but it seems to be kind of chugging along, not really gaining or losing ground, AFAICT.
Single-threaded performance is generally good when natively compiled. In a benchmark I did a few years back, which consisted of traversing the filesystem with `opendir`, `readdir` and friends, OCaml was minimally slower than C++ and Nim (when compiled natively) and around Python and Racket when byte-compiled. It probably would be even faster if I used its imperative features. Looking at the code today I also see some unnecessary copying of lists, which could be mitigated. All in all, I think OCaml has a really good performance considering its high-level semantics. You have to be aware of relative costs of operations, but if you do, "as fast as C" is certainly attainable. OCaml code for the benchmark: https://klibert.pl/posts/walkfiles-ocaml.html and the results: https://klibert.pl/statics/images/walkfiled_perf_test1.png
[1] Actually, I just checked and it looks that `fork` is not implemented, so copy-on-write memory sharing is impossible, even on POSIX systems. Docs: http://caml.inria.fr/pub/docs/manual-ocaml/libunix.html http://caml.inria.fr/pub/docs/manual-ocaml/libref/Unix.html
Unix module docs (with fork!): http://caml.inria.fr/pub/docs/manual-ocaml/libref/Unix.html
I think concurrency is fine (threads and async are options) but parallelism still seems to always be just around the corner and never actually here. I understand part of the problem is making their GC able to handle parallel allocations without hurting basic allocation performance more than they're willing to do.