[yawaramin]

With all the problems arising from leaky abstractions and trying to adapt to a foreign runtime? Imho there's no point. Especially now that OCaml Multicore is on the way. A much better effort, for anyone interested, would be to vastly simplify the OCaml build and package management story to be more Go-like.

[lindig]

> A much better effort, for anyone interested, would be to vastly simplify the OCaml build and package management story to be more Go-like.

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.

[Ericson2314]

> With all the problems arising from leaky abstractions and trying to adapt to a foreign runtime?

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!

[c-cube]

Does Go's runtime do generational collection? No. Does it support tailcalls? I have no idea but I doubt so. Without these there cannot be any chance for OCaml-on-go; more blockers would probably come to mind quite quickly.

[Ericson2314]

The GC would be shitty, yes. I doubt the runtime itself really cares about tailcails. There could be tiny calling convention issue, you can share the runtime while using a different calling convention, I assume.

People forget that the call stack data structure naturally allows tail calls, and restrictions against it invariably have a certain degree of artificiality.

[nu11ptr]

Not sure about now with multicore, but pretty sure OCaml had a "bump" memory allocator previously. These are just a little bit slower than stack allocation as they just involve a pointer increment and is important in functional languages since they allocate a LOT. Go's memory allocator is pretty fast (I played with making a bump allocator for it and it was only 4-5x faster, so very fast), but the slowdown would be noticeable. Also, Go uses a "mark and sweep" style collector (which is the reason it can't use a bump allocator - those require moving on collection, which Go can't do) which just isn't designed for the amount of garbage that FP languages generate. It might work, but it would be quite a bit slower.

[ptman]

Go uses a simple non-generational collector because it avoids generating garbage on the heap by doing escape analysis and allocating on stack. I get the ocaml does a lot of recursion, being functional. But could stack allocation also work for ocaml when using growable stacks?

[yawaramin]

c-cube mentioned a couple, here's another: algebraic effects, or to put it another way, 'resumable exceptions'. Go doesn't even have exceptions natively. The level of indirection this alone would introduce to handle it, would make it an extremely leaky abstraction.

Beware that in your naked grab for users, you don't disappoint them and end up actually driving them away.

[Ericson2314]

Eh just through in a sum type. Unwinding or other runtime support for exceptions is highly overrated in my mind.

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.