> 2. No true parallelism due to runtime limitations (single runtime lock)
I've thought about this, and it's not a big deal in the multicore/SMP sense. For I/O concurrency, there is LWT or Async. It does fall short for "small-scale" parallelism though, eg map-reduce over an array, multiplying big-but-not-huge matrices, etc. At least OCaml doesn't pretend to support threading, unlike most other GIL-bound languages.
For high-concurrency or large parallel problems, multiple processes are a better option since that naturally scales beyond a single machine. OCaml's memory footprint is easily an order of magnitude smaller than eg, Ruby's, so I could run 10x the number of workers using the same resources. And then they'd complete tasks faster, thanks to excellent single-thread performance.
In some sense, OCaml indirectly enables the best of the Unix tool tradition. The maintainers haven't tried to throw the kitchen sink at the language, which practically encourages composable designs where distributed/parallel systems are concerned.
I've thought about this, and it's not a big deal in the multicore/SMP sense. For I/O concurrency, there is LWT or Async. It does fall short for "small-scale" parallelism though, eg map-reduce over an array, multiplying big-but-not-huge matrices, etc. At least OCaml doesn't pretend to support threading, unlike most other GIL-bound languages.
For high-concurrency or large parallel problems, multiple processes are a better option since that naturally scales beyond a single machine. OCaml's memory footprint is easily an order of magnitude smaller than eg, Ruby's, so I could run 10x the number of workers using the same resources. And then they'd complete tasks faster, thanks to excellent single-thread performance.
In some sense, OCaml indirectly enables the best of the Unix tool tradition. The maintainers haven't tried to throw the kitchen sink at the language, which practically encourages composable designs where distributed/parallel systems are concerned.