I'm still waiting for OCaml to get decent multicore support, decent Windows support and an FFI that doesn't suck donkey brains through a straw (which is why so many OCaml libraries, like OpenGL bindings, suck beyond belief). Multicore became ubiquitous 10 years ago. Last I looked the vestigial OCaml community still hadn't noticed.
I certainly wouldn't mind if you could swap out the garbage collector (a la Java - where you can choose between a fast serial garbage collector and a parallel garbage collector). However, I don't think it's the right tool for many tasks.
[1] http://blog.camlcity.org/blog/multicore1.html
[2] http://projects.camlcity.org/projects/dl/ocamlnet-4.0.0test2...
[3] https://ocaml.janestreet.com/ocaml-core/109.24.00/doc/parall...
TBH I don't miss multithreading in OCaml, if you write applications which expose some sort of API over a socket that will scale to clusters, not just multicore. And you can program those kinds of applications quite nicely with Lwt or Async already.
Regarding FFI, ocaml-ctypes is interesting, it allows you to bind to a C library at runtime using pure OCaml (and a wrapper around libffi), or to generate C stubs.
Regarding OpenGL there is a new binding called 'tgls' for OpenGL 3.x/4.x (besides LablGL) that is mostly generated from the XML description of the OpenGL APIs.
Regarding Windows support I can't say much because I don't use it at all, but there was a new 'Self-containted OCaml distribution for Windows' called ocpwin-distrib posted to the ML recently. If you care about Windows support you should probably give them feedback on what is missing.
I just watched it. Great to see somebody else trying but this is no more advanced than OC4MC and they are using Fibonacci as an example when I already used a complete parallel ray tracer with shared memory when benchmarking parallelised HLVM code:
http://flyingfrogblog.blogspot.co.uk/2010/01/naive-paralleli...
They've got a lot of catching up to do before they can overtake and I'm concerned that retrofitting a modern GC on a 20th century VM will never work because OCaml has such poor locality of reference due to massive unnecessary boxing.
> TBH I don't miss multithreading in OCaml,
I said multicore, not multithreading. I dot lots of concurrency and parallelism in F# without having to worry about multithreading.
> if you write applications which expose some sort of API over a socket that will scale to clusters not just multicore.
You're proposing deep copying all of your data structures when multicore programming is all about sharing data between cores using shared caches. If you copy then your identical copies of the data compete for space in a shared cache.
> And you can program those kinds of applications quite nicely with Lwt or Async already.
Lwt and Async are for concurrent programming. In particular, they are extremely slow.
> Regarding FFI, ocaml-ctypes is interesting, it allows you to bind to a C library at runtime using pure OCaml (and a wrapper around libffi), or to generate C stubs.
Ctypes looks great. Didn't exist when I last used OCaml.
> Regarding OpenGL there is a new binding called 'tgls' for OpenGL 3.x/4.x (besides LablGL) that is mostly generated from the XML description of the OpenGL APIs.
Has anyone tried to write anything much using it?
And it will be way slower for all those use cases where I don't need to scale to clusters. Or where it won't actually scale to clusters because I need shared memory, the latency to ask another node is simply too high. I had to move to haskell specifically because of ocaml's "who cares about multicore" stance.