Somebody told me about OCaml’s Riot the other day and I wanted to get some opinions on it. I remember seeing @OvermindDL1 speak highly of OCaml in the past.
1 Like
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 :).
5 Likes
Also sharing mutable data make the GC much more complex, especially if you need to do it across threads.
4 Likes
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.
1 Like
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. 
2 Likes
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…
1 Like
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 
riot/riot/lib/gen_server.ml at main · leostera/riot · GitHub
1 Like
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
I don’t want to accidentally send message to an actor that it can’t process. Plus my long programming practice has shown me that inheritance does not work; it’s semi-implicit and it almost never does what you want it to do. I prefer composition over inheritance, always.
Sorry, I think you don’t understand my point 
Feel free to clarify. 
I think more than one or two developers are in the “I should look at OCaml seriously one day” camp. 
Making $20k/month + housing as an intern out of college at Jane St. is a pretty good deal, I think 
1 Like
They are not helping their own cause by being a bit elitist.
Example 1: you have several stdlib[-like] implementations and just picking each one will you use already puts you in a different part of the community and gives you drastically different options to get help when things inevitably don’t go your way.
Example 2: package and dependency management. I have personally seen mailing lists / forum threads with the ever so helpful “what is dependency management?” sarcastic question. So OK, I have to explain what mix and cargo are doing and, you guessed it, “I never had to use those hippy tools” follows. Very helpful, thanks bro. In the meantime I have no idea how to use a library in my project without having to install it globally.
I have shared this before. It took me a good chunk out of one weekend to just make one “hello world”-like OCaml project that needs two external dependencies and manage them and include them in the project with esy. Literally had to write a script that emulates what a Makefile or Justfile would do, just to have like 10% of what mix or cargo would do.
They don’t seem to think that what we believe are problems are actually problems. This kind of disconnect I feel dooms OCaml to obscurity, and from the little I’ve seen people do with it, that’s a loss for everyone.
Oh, one of my favorite responses are also just linking you the root of the docs of one OCaml’s tools e.g. opam. Cool, my problem is solved right away. (And several times I’ve seen people pointed at docs that don’t contain the answer to their problem anyway, as in this case: opam is used to have different versions of OCaml installed and be able to switch between them, and also to install libraries globally; it can also give you a complete “switch” (an environment really) where you install an OCaml toolchain + all the libraries that you need – they’ll do absolutely anything but not introduce local project dependencies, will they?).
I admit I am out of my depth for OCaml. I recognize some seriously badass smart people are working on it and with it. But they seem fairly uninterested to bring in fresh blood to their ranks and IMO that’s a death knell for that ecosystem, eventually.
Hope I am wrong but historically I wasn’t. Or, best-case scenario: they will be forever in the same niche as they always were. Which I think is a status quo they are fine with.
3 Likes
Yeah but I heard the screening for Jane St. is tough. Not only do you have to invert a binary tree, you’ve got to write an infinite loop that completes in 20 seconds or less.
2 Likes
You went deeper than me but I saw some of this. Lots of recommended packages have literally no documentation beyond the one sentence describing what it is. People say “just read the code”. Ok, thanks.
It’s still a really intriguing language.
2 Likes
Just like our crazy genius uncle Erlang. What’s the problem? 
1 Like
