[pjmlp]

As does OCaml since 1996, no need for sugar substitute instead of using the real deal.

Compiles to native code, has a repl, version 5 is multicore for those not happy with Lwt or multiprocessing in the UNIX classical style of each tool does one thing, and a GC only second to GHC in handling immutable types.

[kevinmgranger]

I get that everyone has their own favorite tools, but "use a version that isn't out yet, or use separate processes for parallelism" is a non-answer.

I'm excited for version 5, but until it's out, it's hard for people to take seriously in conversations about _Go_ of all things.

[wtetzner]

OCaml-on-Go also doesn’t exist…

[pjmlp]

It is more powerful than Go on every sense, and I really don't get what people think using Go runtime into a completly different language would help.

Maybe they should spend more attention in their compiler design classes regarding runtime implementations and language semantics.

[simiones]

I generally agree about the runtime and language semantics.

However, (stable) OCaml not having multithreading support is still a gigantic limitation. Also, OCaml supports fewer target platforms, and I believe it's worse at cross-compiling (though I admit I may be wrong on this).

[wtetzner]

> However, (stable) OCaml not having multithreading support is still a gigantic limitation.

OCaml 5 still seems a lot more real and coming-sooner than the imaginary OCaml-on-Go. Sure, it's not ideal that multicore OCaml isn't yet stable, but it does exist, and will become stable.

[simiones]

Absolutely - I was only replying to the question of why you may want this in principle.

[wtetzner]

My biggest concern would be that Go's runtime is likely not optimized for functional programming.

[pjmlp]

What happened to microservices and UNIX way, each tool does one thing?

Yes, multithreading support is only in version 5.0, yet for many decades UNIX was multi-process only, and thanks to the latest security exploits, sandboxing with multi-processing alongside IPC seems to be the latest fashion anyway, so no big deal.

OCaml has several backends, including a bytecode one that is used for the REPL and porting purposes.

[simiones]

Doing one thing on multiple threads is very much possible. Threads enable (simple) shared memory multi-processing, which is the most efficient version of multi-processing. You can theoretically get something similar with different processes and memory-mapped files, but multi-threading is much easier in general.

For example, if you want a high-performance web server, it's much more efficient to serve requests through multiple threads (preferably also using efficient IO) than it is to spawn different processes for different requests. I imagine you can coordinate different processes in similar ways, but again, it's much more effort, and either way, those processes are far too intimately tied to each other at that point to call them "different tools".

[pjmlp]

They also enable plenty of data races and security exploits, as proven in recent years.