In the last few years OCaml has been tremendously improved with first-class modules, GADTs and multicore. Does that mean SML and other ML languages are doomed or does it just mean the ML ecosystem is more competitive than ever ?
1 Like
Twenty years ago, this question was interesting 
Today, SML has basically no industrial application (aside from a theorem prover), and it is used mostly as a teaching language to gently introduce students to ML. OCaml is, for all intents and purposes, the industrial ML that has commercial adoption.
6 Likes
When I was trying to decide which ML flavour to learn I looked at what packages were available in Debian. It is an imperfect metric, but a package in Debian means that someone has found a particular application or library useful enough to package it (or to request it to be packaged). There were quite a few OCaml packages, but next to no Standard ML packages other than the compilers themselves (AFAICT Isabelle is not packaged), so the choice was clear.
I found it a bit unusual, because coming from C I was expecting a standard, and multiple (competing) implementations. And Standard ML indeed did have that, but it somehow lacked applications. Whereas OCaml didn’t have an associated standard, but did have an evolving set of libraries (even though some of the SML compilers had more advanced features than OCaml did…).
I can’t quite explain why that happened, perhaps OCaml was able to evolve the language more freely without the additional coordination and delays that updating a standard would require, which in turn attracted more users (AFAICT Standard ML itself hasn’t been updated for a very long time, even though there seem to have been some attempts at doing that).
That doesn’t mean that SML should be ignored, in fact now that I know OCaml I should probably look at Standard ML and its compilers, I’m sure there is something there that I could learn about (and maybe apply to improving OCaml itself).
8 Likes
I think there is a static analyzer in the industry (PolySpace) which is written in SML.
They tried to switch to ocaml, but the SML version was significantly faster, so they didn’t in the end.
2 Likes
I think a MLton compiled binary still runs circles around an ocamlopt one - but only on platforms with a native backend 
– which means only x86, I think.
–
Ian
2 Likes
@nobrowser , Could you remember a link to reproducible benchmark, please?
In the last many years, SML offerings have also improved in serious ways, in generic tooling you have millet, smlpkg and smackage, in features you’ve got SuccML RFCs, and various compiler extensions & specific tooling:
- SML#: row-polymorphism for records, better rank-1 polymorphism, first-class sql integration with specific syntax, massive parallelism a la erlang, first-class (but not user-space) overloading, dynamic typing.
- MLKit: memory management via regions, region inference, a graphical memory/region profiler.
- AliceML: extensions for distributed programming (data structures and primitives), dataflow-based implicit synchronization for concurrent programs, constraint-based programming (a la datalog).
- MLton: excellent monomorphising/unboxing and thorough erasure of functional abstractions allow for writing very high level code and expecting good performance still, untagged integers and unboxed floats, support for call/cc, world save/restore, builtin memory + time + counts profiler.
- MPL (a fork of MLton): novel and highly-performant approach to shared-memory parallelism, using a hierarchical gc. it easily competes with (and beats!) OCaml, Go, Java, C++ … in both space and time, despite being a lot less mature.
- SML/NJ: support for call/cc, quote/antiquote macros, a proper implementation of Reppy’s CML.
- Poly/ML: source-level interactive debugger within the language itself, generic pretty-printing & introspection, code generation, a compact compiler distribution which also produces compact executables.
- a bunch others worth looking at: cakeml, manticore, mlworks, moscow, sosml, …
So if you don’t really use FCMs and GADTs heavily, and you don’t consider your project “industrial” with its reliance on multitudes of dependencies from opam, and are interested in one of those features, SML can be a compelling choice.
Of course I’m team OCaml and I think it’s a lot nicer of a language + tooling + ecosystem, but I do think there’s a lot to learn from SML, and I’m all for ML unity!
12 Likes
Isn’t MLton whole program optimization ? I can image compile times being huge if we’re compiling a big piece of code.
1 Like
Yeah some people use PolyML to do incremental development because it’s faster, then MLton to do production builds because it’s more optimized. The problem is that there are a ton of different compilers, each with its own quirks. So you have to be very careful about what features you use. It’s like testing your database code with SQLite and deploying it with Postgres.
1 Like
They probably differ less than 2 successive Ocaml releases
–
Ian
Yes. I didn’t mean to imply anything about compile times.
Also notable in MLton is the “basis system” which fixes – or at least renders harmless – the worst SML language bug IMO, namely the missing alignment between modules and overloading.
By the way, I didn’t know about MPL. Can you share a link please? Thanks.
–
Ian
I think he meant this MLton-forked compiler for Parallel ML.
The performance of MLton is very real. This new parallel compiler seems similarly impressive. Shame it’s for SML.
2 Likes
Thanks. Sadly github seems very broken today for me (Firefox on Linux). Looks like a big update of the site with testing only on Chrom*kids.
–
Ian