I find it interesting as it seems to generate little "buzz", but has two new books this year, and is a pre-cursor to another functional language that itself seems to be gaining traction, and is yet produced my Microsoft: F#
My observational / untested impression is OCaml seems to be more practical, and maybe a little easier to transition to for someone like me who uses mostly Python and Go, and a lot of bash/awk/sed/grep.
If you want to use a functional language on Unix, _and_ have a type system, _and_ avoid JVM/.Net then you don't have many choices.
There is Haskell of course, but it is lazy by default, which makes it harder to reason about how your program will execute, and how much space it'll use.
Rust is something interesting to keep an eye on, but AFAIK it is not ready yet for production use.
Hence I prefer OCaml.
From the little I know of OCaml, Rust isn't really in the same category. While it has functional elements, it's really aimed at being a cleaner C++ (for instance, it doesn't have TCO).
I was shown some OCaml code at the university, so learning OCaml later seemed easier than Standard ML.
Also I use Debian, and after a quick look at the repositories it has far more libraries for OCaml (-ocaml-dev) than for Standard ML, which tipped the balance in favour of OCaml as the language that I wanted to learn.
Why did I stick with OCaml after that? Mostly for two reasons: there are some libraries that I like (OCamlnet, Lwt, just to mention a few), and the community appears to be more active in recent years (lots of work on build systems, packaging, new libraries coming out, user meetings, etc.).
TBH I never followed the Standard ML community, so I don't know if its similar.
A major limiting factor is that OCaml has no support for parallelism, and due to it's use of a global interpreter lock for GC it can't run multiple threads.
That said it's great to program in (like Haskell with convenient IO and semicolons) and it compiles to blazing fast executables.
This is by choice, because single thread performance matters more, and you can use fork or MPI to scale across NUMA nodes and clusters much more scalably and safely.
Having used fork/join to parallelize an OCaml genetic algorithm, I can say from experience it is neither safe nor practical.
Edit: Intentionally only supporting single-threaded processes is a perfectly fine design decision, however I haven't seen this argument made for OCaml, rather I've seen "multi-threading our GC would be hard" as the justification for the single-thread limitation. Admittedly it was 3-4 years ago when I last had to deal with this.
There are now several experimental multithreaded OCaml runtimes floating around, which also have the key property of not slowing down the single-threaded case. I don't expect multicore to remain a limitation for OCaml in 2014.
I think people are starting to see the value, or at least popularity, of functional languages (Haskell/Scala/F#), and some of those are picking up OCaml as a language that fits into their workflow better - one that compiles to native binaries, without the extreme functional purity of Haskell.
I did read (and comment a bit) on the 'Real World Ocaml' beta book, but I've already known and used the language for quite some time before, so I can't really judge which book would be better for a beginner. Take this with a grain of salt:
"OCaml from the very beginning" seems to focus more on teaching the language itself. If you've never used OCaml before then this might be the place to start.
"Real World OCaml" in addition to teaching the basics of the language has some intermediate-level chapters (dealing with json, S-expressions, asynchronous events, parsing), and some advanced-level chapters (GC, compiler frontend/backend). I definitely recommend reading it at some point.
I have been taught fundamental concepts of programming and programming paradigms with OCaml, and I am very grateful for that. To me, it is an expressive, clean, powerful multi-paradigm language that deserves a lot of love.
I find it interesting as it seems to generate little "buzz", but has two new books this year, and is a pre-cursor to another functional language that itself seems to be gaining traction, and is yet produced my Microsoft: F#
My observational / untested impression is OCaml seems to be more practical, and maybe a little easier to transition to for someone like me who uses mostly Python and Go, and a lot of bash/awk/sed/grep.