Hacker News new | past | comments | ask | show | jobs | submit login

A major limiting factor is that OCaml has no support for parallelism, and due to it's use of a global interpreter lock for GC it can't run multiple threads.

That said it's great to program in (like Haskell with convenient IO and semicolons) and it compiles to blazing fast executables.

This is by choice, because single thread performance matters more, and you can use fork or MPI to scale across NUMA nodes and clusters much more scalably and safely.

Having used fork/join to parallelize an OCaml genetic algorithm, I can say from experience it is neither safe nor practical.

Edit: Intentionally only supporting single-threaded processes is a perfectly fine design decision, however I haven't seen this argument made for OCaml, rather I've seen "multi-threading our GC would be hard" as the justification for the single-thread limitation. Admittedly it was 3-4 years ago when I last had to deal with this.

There are now several experimental multithreaded OCaml runtimes floating around, which also have the key property of not slowing down the single-threaded case. I don't expect multicore to remain a limitation for OCaml in 2014.

My impression was that the core team was actively opposed to adding parallelism support. Has this changed?

That's a feature not a bug; it would slow down Coq is the reason.

Haskell has optional semicolons, though it probably isn't idiomatic to use them most of the time.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact