My wish for Ocaml is that it could somehow be popular enough to have more… casual users, let’s say. I enjoy playing with it more than any other language I’ve run into, but everyone else falls so deeply into it that I don’t generally follow their discussions very well. (Maybe I’ll fall in deep myself in time, but it remains to be seen.)
Huh? The point is Go might be a lousy language, but I can't think of anything OCaml needs to do that the Go runtime cannot do. This wouldn't be leaky and the FFI could be quite good.
> Especially now that OCaml Multicore is on the way.
As I wrote in the other reply, this would be a naked ploy for new users, and flexing the language isn't wedded to a single run time.
Multicore OCaml isn't just a runtime change, but also demonstration of the new effects indicating that the language can do parallelism without bad concurrency problems. All that language-side work carries over to the other runtime: you get to show off Goroutines done more safely!
People forget that the call stack data structure naturally allows tail calls, and restrictions against it invariably have a certain degree of artificiality.
Beware that in your naked grab for users, you don't disappoint them and end up actually driving them away.
What's really dank is doing https://www.ccs.neu.edu/home/shivers/papers/mrlc-jfp.pdf i.e. multiple return pointers. This way you can do the Rust Result (Either Monad) thing without branching.
OCaml's package management and build system is not complicated for consumers and builds are very fast. What do you feel is complicated about opam and dune?
What is complicated (but got better) is submitting packages into the official package repository. However, this ensures that packages have correctly versioned dependencies, which is good for consumers.
Go does not rely on a central package repository and this makes it easier to use by essentially just pointing to GitHub. OCaml and Go differ in the way they try to use updated dependencies for a build. OCaml by default is aggressive whereas Go prefers stability.
OCaml on the other hand has an extremely well optimized runtime for lots of small heap allocations (typical in FP), and produces good asm code for functional patterns.