Hacker News new | ask | show | jobs
by pjmlp 1356 days ago
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.
1 comments
simiones 1356 days ago
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).

link
wtetzner 1356 days ago
> 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.

link
simiones 1356 days ago
Absolutely - I was only replying to the question of why you may want this in principle.
link
wtetzner 1356 days ago
My biggest concern would be that Go's runtime is likely not optimized for functional programming.
link
pjmlp 1356 days ago
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.

link
simiones 1356 days ago
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".

link
pjmlp 1356 days ago
They also enable plenty of data races and security exploits, as proven in recent years.
link