I considered picking up OCaml at one point, but got scared off by the global interpreter lock. Can an experienced OCaml dev tell me when this would really become an issue, and certain cases where it wouldn't make a difference?
My experience has been building parallel and distributed programs using multiple runtime instances that communicate via message passing. There are libraries that help automate this, link our own Async_parallel (https://blogs.janestreet.com/async-parallel/). One advantage of this approach is that it scales beyond a single box.
There is work going on at OCaml Labs on a parallel runtime. I suspect it will be useful, but in the end, message passing is I think a better idiom than shared memory threads for parallel programming. When the true parallel runtime lands, I'm not sure that we'll actually use it much for running truly parallel threads.
> I suspect it will be useful, but in the end, message passing is I think a better idiom than shared memory threads for parallel programming.
It really depends on the problem you are working with. You wouldn't want to make a high-performance HTTP server this way. Especially if you get to copy 2MB of POST data every time.
For an HTTP server you should use Async or LWT, which are lightweight concurrency libraries. You can handle quite high levels of concurrency with either one. My impression is that people building highly parallel HTTP servers do quite well with collections of processes with a load-balancer in front, but it's not my area of expertise.
Async and LWT give you lightweight concurrency mechanisms. Libraries like Async.RPC give you lightweight remote invocation, and Async_parallel gives you simple mechanisms for spinning up multiple physical processes and communicating between them.
Don't get me wrong: OTP by all accounts has richer support for this kind of stuff. I think OCaml is a better language for many purposes, but OTP is a great runtime and set of libraries whose equal is not yet found in any other language as far as I can tell.
