This is a real problem with ML. There's competing tooling from SML/NJ and MLton, not to mention interesting, useful projects like MoscowML or PolyML. So finding

This is a real problem with ML. There's competing tooling from SML/NJ and MLton, not to mention interesting, useful projects like MoscowML or PolyML. So finding reusable libraries and such is a real battle, and you can't escape knowing both MLBasis and CM, as well as SML/NJ extensions and differences in the respective Basis libraries. The underlying "problem" is that MLton is too good to ignore, but takes so long for even small programs that it's impractical for day-to-day, let alone interactive development. That's what's so exciting about new work on MLton like this: A JIT-ing MLton, for instance, could be an amazing thing. It seems like the community has been coalescing around MLton against all odds, and any improvements to it are a big deal. SML is nicer syntactically than OCaml, but OCaml brings so much to the table that it's hard to ignore (a simpler compilation model, niceties like named arguments, single development target, good community). Also Paulson's ML For the Working Programmer explains SML's warts well, in a historical context. It goes into great detail of some of the limitations of SML's module type safety and some of the nasty things you need to do to make functors generic and reusable, which really turned me off of the language and explained why Caml and OCaml exist. I still love SML but must concede that it's mostly a teaching language. The Little MLer is wonderful.