However pulling these over more than 1 core is still a problem. OCaml 4.05.0 should have infrastructure for that (although OCaml multicore has been somewhat a `duke-nukem forever` story)
Compared to Go, OCaml is unfortunately a rather large language. It has many non-orthogonal features, some of which are not used widely. The impression I get from Go programmers is that the small size of the language is one of the chief attractors.
> Compared to Go, OCaml is unfortunately a rather large language.
I agree. That said, ML is definitely a small language like Go, without OCaml's extras like the object system.
Alas, ML lacks Go's awesome and very modern standard library, which is a key part of Go's allure.
But yes, I would adore a functional language with Go's best features, particularly the standard library, solid concurrency, simplicity/ease-of-learning, fast compiles, binaries, static, etc.
There's also Standard ML, which smaller, and fully specified, with multiple implementations.
But I think part of the problem with both is tooling. Build and dependency tooling in particular. Opam was a good step in the right direction, but I think OCaml and SML could both benefit from a Cargo-like tool, that made managing projects and their dependencies simpler.
However pulling these over more than 1 core is still a problem. OCaml 4.05.0 should have infrastructure for that (although OCaml multicore has been somewhat a `duke-nukem forever` story)