It is hard to cross from academia to commerce. The changes that were (and are) needed to O'Caml are not things that will result in publications, and thus don't fit the academic funding model. At the same time they are a precursor to attracting wider interest in the language. It seems that a benefactor like Jane Street is needed for this to occur. Certainly it seems that Jane Street is eager to spend money to fix this problem.
The story of O'Caml is a good reminder that in language adoption, as in business, execution, along with a bit of luck, what matters. The world is full of could-have-beens. And on that note, I've got code to write...
During the same time using GODI to install a xml processing library completely hosed my system after me foolishly granting it root rights, which killed my OCaml enthusiasm for good.
OCaml is in itself a really nice language (apart from some warts like lack of native multithreading support) but it's tooling, infrastructure and "first developer experience" and lack of progress in these areas in the last years is beyond atrocious (compared to F#, Scala, Clojure, Haskell, Ruby, Python, JavaScript).
Now, implementation of typeclasses is pretty-well documented, so if anyone's willing to finance OCamlPro on this, I don't think there's any technological or scientific barrier.
There's also Yeti ( http://mth.github.com/yeti/ ), an ML for the JVM, though I'm not sure how mature it is yet.
It does need more libraries but it's also extremely interoperable with Java/JVM. Very simple and easy to call out to Java libraries. Also compiles to native JVM classes (can be called easily from Java).
For anyone interested, I managed to write a Mustache implementation last weekend:
However, experience shows that, at least in presence of sufficient RAM and for code that runs long enough, the combination of VM + JIT beats fast machine-code. For sources, see the Big Language Shootout (nowadays, JIT-compiled Java ranks above OCaml and even C in many benchmarks) or the Dynamo papers (JIT-recompiled native C beating optimized native C by about 5% on reference benchmarks).
In addition, having a VM + JIT allows for very nice tricks. For instance, recent versions of MacOS X use LLVM code that is dynamically targeted to either the CPU (generally predictable when you're building the application) or the machine GPU (much harder to predict) depending on available resources. If one thinks in terms of distributed/cloud resources rather than one computer, it also makes sense to target one specific architecture at the latest possible instant (e.g. during deployment, possibly even after work-stealing), to be able to take advantage of heterogeneous architectures. Also, the VM + JIT combination paves the way for extremely powerful debugging primitives, or for late optimizations that just can't be performed during compilation due to lack of information.
So, in the long run, it's quite possible that efficient machine-code will be relegated to niches (e.g. system development), while JIT-ed code will [continue to] take over the world.
