OCaml Riot, an actor-model multi core scheduler - thoughts?

Ocaml 5 is definitively hot technology and the whole language is a beauty! I am not an Ocaml expert, though I can see two technical difficulties in general:

• Shared mutable state
• Garbage collection

Unlike Rust, Ocaml does not have “fearless concurrency”. As long as shared mutable state stays within the same scheduler thread, everything should be fine but once you start sharing it between threads, you easily shoot yourself into your foot.

From a performance perspective, the Ocaml GC used to be stop-the-world, not sure if this is still true for Ocaml 5.

Rust got plenty of these actor-model libraries, including one modeled after Pony’s actor system: Michael Neumann / tractor · GitLab (disclaimer: I wrote it :).

Also sharing mutable data make the GC much more complex, especially if you need to do it across threads.

I believe they are quite aware of it and that’s why they are pushing hard to make their effects library have a stable API next, if memory serves well.

https://github.com/ocaml-multicore/ocaml-effects-tutorial

I haven’t been paying close attention, but there are some deep-dives into the process of getting OCaml to play well with multicore that are a good read:

As to Riot itself, at a glance the code example looks… like BEAM process-handling code written with an ML flavor.

Don’t forget strong static typing. To me that’s an improvement, though I never could find the bandwidth to learn OCaml. I am using my extra energy and time to learn async Rust better and boy, does it drain that and a lot more…

YMMV; as commonly encountered in strongly-typed messaging systems, the need to add every possible message shape to Riot.Message.t seems suboptimal.

Overall it seems very early on - for instance, the implementation of GenServer.call doesn’t currently use the selective-receive functionality, so sending a message to a process that’s waiting for a reply to a call will make it crash https://github.com/leostera/riot/blob/main/riot/lib/gen_server.ml#L23-L32

YMMV indeed, to me that’s a feature. Messages should be strongly typed, they are a discrete set anyway and I’d love to know them all beforehand, not discover them afterwards (especially not through my error alerting system).

Seems like it, yeah. I know a few other Rust actor implementations that seems more mature – but I have no visibility if their maintainers will keep developing them (though 1-2 of them seem quite complete). Still had no opportunity to try them though.

YMMV indeed, to me that’s a feature. Messages should be strongly typed, they are a discrete set anyway and I’d love to know them all beforehand, not discover them afterwards (especially not through my error alerting system).

Types aren’t the issue. The issue is having a single type for messages.

We don’t actually need a single type for messages. You can have one type per actor, and that type is a sum type (enum in Rust parlance). To me that works great.

Do you have a reference for this allegation? For me, it seems that Riot supports a single type for messages, which is the extensible variant Message.t