[nonameiguess]

SML is great as a language, but has terrible tooling and a balkanized ecosystem of incompatible implementations, many of which only support REPL workflows (and these tend to be the implementations used for teaching). These are a far cry from the typical "point a compiler at a build file and go" that developers are used to. Go may be a strictly worse language as a language but still be better for building and distributing applications. SML is also very poorly documented, and it is rarely clear which implementation's documentation you're even reading when you find something on the web, which can often lead to quite a bit of frustration. Go, on the other hand, is extremely well-documented.

[hajile]

SML doesn't have "incompatible" implementations per-se. If you stick with what the standardized language and basis libraries specify, your code will compile everywhere (I don't know of any popular implementation that doesn't support the spec). If you use their proprietary extra features, then portability will naturally go down.

The primary means of developing uses SML/NJ for development and MLton for the final, optimized build. Both use the same Compilation Manager[0] and generally share the same ecosystem so using them together pretty much just works.

[0] https://www.smlnj.org/doc/CM/new.pdf

[BeetleB]

Your parent acknowledged everything you said in his comment.