[1] https://discuss.ocaml.org/t/multicore-ocaml-may-2020-update/...
I wouldn't go so far as to say OCaml is more interesting. F# has things like computation expressions, async, units of measure, and type providers, none of which are trivial (or exist in OCaml), several of which are incredibly influential, and all of which are interesting. The long slog towards multicore for the OCaml community has been kind of embarrassing, with Haskell having offered arguably the best concurrent and parallel programming support in all of software development for years and years now.
I will also note that F# gets new features fairly frequently as well, is cross-platform, and is extremely fast by virtue of running on the CLR, which I would not underestimate: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
The features that it is missing from OCaml are admittedly pretty major, though. Row polymorphic records and the structurally typed object system are missed, not to mention rich modules and functors.
It definitely has async: https://github.com/ocsigen/lwt
It doesn't have units of measure but due to strong abstraction properties of modules we can fairly easily roll abstract types.
It doesn't have type providers but it does have plugins for type-directed derivation of JSON codecs, equality, comparison, printing, etc.
> The long slog towards multicore for the OCaml community has been kind of embarrassing
IMHO it's been refreshing to see the pushback against 'multicore at all costs'. There is a benefit to taking the time to do things the right way. OCaml is a 30+ year-old language with an even longer ML heritage. It's going to be around for a while; it doesn't need to rush into a sub-par implementation. Meanwhile, people are writing highly concurrent, multi-threaded applications with it right now, and using multiple processes just fine for parallel computing.
Type providers are a native feature, no plugins required. I have no animosity towards OCaml (in syntax and semantics, I prefer it!) but this is a bit of a stretch.
I don’t think anyone would say Haskell does multicore the “wrong” way, and OCaml as you say has had decades to solve these problems. I love the language but the community is very small and the language evolution has been extremely conservative for the most part.
Yes, units of measure are really cool, and I understand they support dimensional analysis out of the box. It's quite unique, and I fully agree that abstract types don't fully replace them. Just saying that that's what people do in OCaml.
> I don’t think anyone would say Haskell does multicore the “wrong” way
And it certainly is not something that I said.
> OCaml as you say has had decades to solve these problems.
The 'problems' being the lack of multicore support? As I said, this is not really stopping people from getting real work done in industry–see everyone using OCaml currently in highly concurrent and multi-process parallelized applications, or in fact even people using NodeJS, Python, Ruby.
> the community is very small
Correct, but it is definitely growing.
> and the language evolution has been extremely conservative for the most part.
Not so correct. There have been massive amounts of changes in the last few years: https://www.ocamlpro.com/2019/09/20/a-look-back-on-ocaml/
And this is not even taking into account the features which OCaml had before then beyond F#:
- Polymorphic variant types - Structural subtyped object types - Named arguments - Optional arguments - Functors
I’ve interviewed with Jane Street and gotten an offer on the basis of my OCaml and F# skills. I understand where these ecosystems differ. I rest my case.
> Named arguments are allowed only for methods, not for let-bound functions, function values, or lambda expressions.
> ...
> Optional parameters are permitted only on members, not on functions created by using let bindings.
The major pain points are the tools. I tried setting everything up two years ago, or so, and I couldn't do it. While the language might be good (modules) everything else isn't.
and ocaml isn’t always faster