Regarding build systems, ocamlbuild is included with the standard ocaml distribution and gives a high-level interface that is much simpler to use than ocamldep and friends. Especially when combined with findlib.
The user group explicitly rejected multithreading at the OCaml Users conference a couple of years back. (There was a working implementation called oc4mc).
The reasons were that it will slow down single-threaded performance, and threads as a programming model is not robust (compared to, eg. forking, message passing, MPI etc). Also actual graphs of 4- and 8-way SMP performance showed pretty poor scaling for real problems, so the benefits aren't that great compared to going for full MPI, which you have to do for NUMA anyhow.
GHC has a compiler flag to enable multi threaded runtime. Why can't OCaml have that? It is a bit rigid to have to build two versions of a binary, but for folks who run their own code, no problem at all.
Sure, you can run OCaml and oc4mc. You'll also end up with two different binaries. oc4mc isn't as well tested, so I guess you'll hit more bugs. This still doesn't solve the horrible programming model [I've been cursing a multithreaded C program in the past few days. It's amazing how much stuff you have to remember and how much simply doesn't work in C when you've got threads]. Nor does it let your program scale past the limit of a single NUMA node. Whereas message passing a la Erlang lets you scale over NUMA and across machines and networks.
there were some attempts to include multithreading into standard ml. john reppy's manticore project came quite far but wasn't fully implemented.
currently mythryl, a sml/nj derivative with c-flavored syntax, is about to get a full multithreading support. check out mythryl.org and the status updates on the mailing list.
F# is practically OCaml, from my understanding. I don't know if it has all the same current .NET multithreading support under Mono. Worth looking into.
They really diverge when it comes to more advanced language features. I make heavy use of functors in my code and my (possibly mistaken) understanding is that F# simply doesn't support them. Ditto for first-class modules, polymorphic variants, GADTs, and OCaml's object system. Of course, in exchange for a wimpier core, F# gives you a lot of convenient polish and proper support for parallelism & concurrency.
ML functors aren't the same thing as the functors or applicative functors I often blog about. Difference explained here: http://stackoverflow.com/questions/2030863/in-functional-pro...
ML functors are like parameterized modules. F# doesn't have parameterized modules, but has parameterized classes, which work quite similarly. Classes/objects can also be used as first-class modules.
What .NET lacks (therefore also F#) is type constructor abstraction, which means you can't generically express the concept of a (Haskell) functor, applicative functor, monad, etc.
My understanding is the same. I, like you, haven't followed F# since it diverged so much in development, but it's understandable that those features would be in-commensurable with how it interoperates with the .NET framework.
