It's back up now; the ML TCP stack was running a pcap dumper for debugging, which didn't cope well with a hackernews link.
Hacking is going pretty well on Mirage. The longer-term plan is to generalise the support libraries to work with other languages (particularly HalVM and GuestVM for Java), but it's far simpler to work with just OCaml for getting the first cut out. The Xen Cloud toolstack (also written in OCaml) is currently being adapted to support low-latency microkernel establishment, which will remove much of the hassle of coordinating multiple Mirage 'processes'.
Another interesting performance-related aspect has been the heavy IPC workloads that result from using many VM-VM interconnects. Some early benchmarks in http://anil.recoil.org/papers/2012-resolve-fable.pdf .
I know, and I'm tepidly excited, but I'd had high hopes for Practical OCaml, too, and ended up being sorely disappointed. There's lots of good reasons to believe that Real World OCaml will be a totally different beast, but I'm trying to hold my enthusiasm until we get a bit closer to when it ships.
Note that OCaml is just fine for heavy math and data stuff: the garbage collector has a global lock, but threads work just fine for CPU intensive activities. Just don't generate much garbage (which is important for any data-heavy processing), and all is good.
The first three are indeed a big irritation, and a big motivation during writing this book. There is a lot of work going on to improve all of these at the moment, notably through Core from Jane Street providing a well-maintained accessible standard library, and a convergence of packaging systems. The good folks at OCamlPro are also working hard to better editor and documentation support, so I except there will exist a documentation/package repository before this book is released.
OCaml isn't actually a pure functional language: it has side-effects and mutation. In fact, you can code that looks an awful lot like C if you want, except with automatic type inference. But then you can also lift up your level of abstraction in the same codebase to use a purely functional idiom where it's appropriate, or use an object-oriented style for something else. All of those styles are supported as consistent, first-class features in the language.
There are several event-driven programming libraries in OCaml, and two that I like that use monadic abstractions (to hide the messy control flow that makes node.js so painful) are Async (https://ocaml.janestreet.com/?q=node%2F100) and Lwt (http://ocsigen.org).
You have good low-level memory layout in OCaml, either via an FFI or the Ancient module to import in non-GCed values. You can read about the OCaml heap and GC at this blog series by Richard Jones. http://rwmj.wordpress.com/2009/08/04/ocaml-internals/ (and yes, the memory representation is a straightforward mapping from the type declaration; very little magic happens in the compiler)
OCaml is used all over the Xen Cloud Platform (http://github.com/xen-org/xen-api), and I'm running an ongoing microkernel research project called Mirage (http://www.openmirage.org) which has a full network stack written in pure OCaml (and is also competitive performance-wise).
Very cool, thank you. I watched the openmirage talk since I'm interested in distributed computing -- this is great work. I like anything that gets rid of excessive layers, and the typical cloud stack is really suffering from this.
I have been meaning to give OCaml a try for awhile but it's bumped on my list now. (Though it seems that the thing that people keep complaining about is lack of a polymorphic print...)
Hacking is going pretty well on Mirage. The longer-term plan is to generalise the support libraries to work with other languages (particularly HalVM and GuestVM for Java), but it's far simpler to work with just OCaml for getting the first cut out. The Xen Cloud toolstack (also written in OCaml) is currently being adapted to support low-latency microkernel establishment, which will remove much of the hassle of coordinating multiple Mirage 'processes'.
Another interesting performance-related aspect has been the heavy IPC workloads that result from using many VM-VM interconnects. Some early benchmarks in http://anil.recoil.org/papers/2012-resolve-fable.pdf .