Overall, great article and great code. Let's keep in mind that SML is typically taught to entry-level CS students (some of them with no programming experience) at universities like CMU, where often a term project might actually be an ML compiler in ML. It's not a terribly complex language and some limitations (which I am not going to state here) aside it has a great use to play.
It should be noted that XenServer also uses OCaml. While it's not really fair to compare Go with OCaml (the language roots are vastly different as are the philosophies -- aside from the idea that "static typing shouldn't mean typing so much you generate static electricity") both seem to do best in the "userland systems programming" niche -- that awkward place where C++ is needlessly painful, Java is ill-fitted, and python/etc... simply inappropriate.
For an API that has 400 or so calls accessible through a dozen different programming languages, this makes sense. The bindings in each language are never out of date or wrong (except of course they can have a systematic bug, but those are much easier to fix).
This also makes it very easy to generate alternate "views" of the same API, like OCaml module vs OO views.
Also virt-builder is very procedural:
It's "do this, then run this, and if this condition is true do something else". OCaml's strengths here are its brevity, speed and safety. No complicated features are used, eg. no functors, no difficult use of functions as first-class objects ...
(I'm not actually a fan of functors; I think they obscure the flow of the code, in the same way as using inheritance in OO).
While functors aren't something to us every day, aren't they more of an equivalent to the Decorator pattern in OO (which is more about composition and inheritance of interfaces as opposed to inheritance of concrete implementations which I agree is something to avoid)?
That said, I think I see what you mean -- I've found myself using functors needlessly because I've previously used adapters in their place in Java; instead, it may have been for it for me to ask myself what the real problem I'm trying to solve is.
We're somewhat limited in terms of dependencies. We can add a dependency, but it needs to be available on all platforms we support (Fedora, Debian, Arch, SuSE, Gentoo, OS X would be the main ones). Of course this is an argument against OCaml, but so far we've been fine needing only a handful of libraries and liberally calling out to C.
Huh? FORTH is one of the most simple programming languages around.
My anecdata tells me that Go's types are sufficient (and sometimes even handy), error handling everywhere helps more than it hurts (and is easily ignored if you want to), and is very much not a functional language. And I would disagree with the notion that C is, on average, well-understood given how widely available it is (a nicer way of saying that C is an easy language for anyone to misunderstand). Go is comparatively simpler to 'get right' -- in my experience
Again, this is all very subjective. Still, I don't see how flaming Go alone helps highlight OCaml's advantages and contrast their tradeoffs.
OCaml is almost 20 years old now, which is about the right amount of time to start trusting a language for mission critical code :)
Some of our experiences in Xen that we wrote up for ICFP 2010: http://anil.recoil.org/papers/2010-icfp-xen.pdf
And lots of source code: