Really looking forward to what the community will build with OCaml 5.00! IMO it will shoot the language straight into the mainstream and I can't wait. OCaml is applicable for like 90% what's out there, including as a Python replacement. And its syntax is often much terser than Rust (although the higher-level typing constructs can be confusing to read).

After that, all that's left is a tool like Elixir's mix or Rust's cargo and the language is basically not only in the 21st century but much farther than many others! Looking forward to it.

i.e. previously some code could've in theory assumed it only ever gets called by one thread at a time due to the global lock (and that lock would get dropped in a controlled manner by the usual released/acquire). I don't necessarily mean just global state in the C stubs (I don't recall seeing many of those), but implicit global/shared state in the C functions called. Reading manpages will usually tell whether a given function is safe to be called (or when not there are sometimes _r variants that are). This is no different than when writing regular multithreaded C code, one has to be more careful about what functions they can safely call. (and in fact current OCaml code can already be multithreaded, so if the C stub was meant to work correctly with multithreaded OCaml code with C->OCaml callbacks then it should've already taken necessary precautions).

I like the approach taken wrt to backward compatibility of sequential code though: only code that wants to take advantage of multicore will need to audit its C stubs for safety, if you don't use multicore everything will work as before.

How do you recommend to find these kinds of multicore-specific bugs in existing (or newly written) OCaml-C stubs? Would tools like parafuzz help here?

- domainslib schedules all tasks across all cores (like Go).

- eio keeps tasks on the same core (and you can use a shared job queue to distribute work between cores if you want).

Eio can certainly do async IO on multiple cores.

Moving tasks freely between cores has some major downsides - for example every time a Go program wants to access a shared value, it needs to take a mutex (and be careful to avoid deadlocks). Such races can be very hard to debug.

I suspect that the extra reliability is often worth the cost of sometimes having unbalanced workloads between cores. We're still investigating how big this effect is. When I worked at Docker, we spent a lot of time dealing with races in the Go code, even though almost nothing in Docker is CPU intensive!

For a group of tasks on a single core, you can be sure that e.g. incrementing a counter or scanning an array is an atomic operation. Only blocking operations (such as reading from a file or socket) can allow something else to run. And eio schedules tasks deterministically, so if you test with (deterministic) mocks then the trace of your tests is deterministic too. Eio's own unit-tests are mostly expect-based tests where the test just checks that the trace output matches the recorded trace, for example.

The Eio README has more information, plus a getting-started guide: https://github.com/ocaml-multicore/eio/blob/main/README.md