4 ms·

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 excite

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 4y ago
OCaml-on-Go also doesn’t exist…
pjmlp 4y 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.
- simiones 4y 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).
  - pjmlp 4y 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.
    - simiones 4y 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".
      - pjmlp 4y ago
        They also enable plenty of data races and security exploits, as proven in recent years.
  - wtetzner 4y 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.
    - simiones 4y ago
      Absolutely - I was only replying to the question of why you may want this in principle.
      - wtetzner 4y ago
        My biggest concern would be that Go's runtime is likely not optimized for functional programming.

wtetzner 4y ago

OCaml-on-Go also doesn’t exist…

pjmlp 4y 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.

simiones 4y 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).
- pjmlp 4y 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.
  - simiones 4y 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".
    - pjmlp 4y ago
      They also enable plenty of data races and security exploits, as proven in recent years.
- wtetzner 4y 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.
  - simiones 4y ago
    Absolutely - I was only replying to the question of why you may want this in principle.
    - wtetzner 4y ago
      My biggest concern would be that Go's runtime is likely not optimized for functional programming.