[jdh30]

> SML has stagnated for almost 20 years

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.

[adultSwim]

The netmulticore library [1,2] worked well for me. The style there is to spawn worker processes and pass messages between them. I'm not sure how popular that library got but that style of programming seems to be pretty popular among OCaml users who need it. Many projects use something lighter-weight or just roll their own (e.g. Parallel in Jane Street's ocaml-core looks pretty good [3]).

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...

[edwintorok]

Have a look at the 'Multicore OCaml' presentation here: https://ocaml.org/meetings/ocaml/2014/

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.

[jdh30]

> Have a look at the 'Multicore OCaml' presentation here: https://ocaml.org/meetings/ocaml/2014/

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?

[shadowfox]

Side note on Windows distributions: Besides ocpwin-distrib there is also Wodi [1] which started as a port of Godi and is fairly stable on windows.

[1] http://wodi.forge.ocamlcore.org/

[imanaccount247]

>if you write applications which expose some sort of API over a socket that will scale to clusters, not just multicore

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.