brightball
OCaml Riot, an actor-model multi core scheduler - thoughts?
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.
Most Liked
yawaramin
Hello, I checked this thread a while back and there were no replies, forgot to check back and I see now there are a few ![]()
Overall I think Riot is exciting. The creator (Leandro) is a long-time Elixir hacker and OCaml legend. He is also very focused on DX and making libraries with great documentation and design. I have every confidence that the Riot ecosystem he is creating is going to be extraordinary.
Let me address a couple of things that caught my eye in this thread.
Riot does, yes, but that’s a design decision in this library and not an inherent limitation of statically-typed actor systems. For example see Akka, which has typed actors with distinct message types: Introduction to Actors • Akka core
As you can imagine, having multiple ‘standard libraries’ is not centrally planned by the OCaml community. Different people make different libraries that solve their problems. My advice is to stick with the default Stdlib that ships with OCaml until you need something specific, then add the specific library eg uuseg for Unicode string segmentation.
Example 2: package and dependency management. I have personally seen mailing lists / forum threads with the ever so helpful “what is dependency management?”
In every community, you will find some bored cranks who question every modern practice as a matter of course, it doesn’t mean that is the majority opinion. And in fact there are multiple OCaml teams working hard on package management concerns.
- Tarides are working hard to produce welcoming opam package management content: [BLOG] opam 101: the first steps, by OCamlPro - Learning - OCaml
- Dune people are working hard on integrating package management directly into the build system: OCaml Platform Newsletter: November and December 2023 - Community - OCaml
There’s a lot of effort to bring the community into the modern era. Things are looking very exciting. And Riot is going to take OCaml 5 Multicore to the next level with massive concurrency. It’s super exciting.
mneumann
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 :).
rvirding
Also sharing mutable data make the GC much more complex, especially if you need to do it across threads.
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









