2022-08-06
So, at my job one of the main languages my team uses is Ruby (the other main one is Kotlin). Recently we started an effort to update our codebase and dependencies to be Ruby 3 compatible. One of the new features introduced is Ractors (aka Ruby Actors), which introduces Actors to the language. The main draw of Actors is having simpler parallelism with less footguns by using message passing instead of shared memory for intra-process data communication. I really recommend reading the Ractor docs, as they are clear and to the point.
This caught my eye because I’ve learnt some Erlang in the past (using the excelent and highly recommended Learn you some Erlang book), and I loved the language and the OTP (it didn’t hurt that I also love Prolog, and Erlang is a descendant of it). The whole language and VM is oriented towards the Actor paradigm (which are called “processes”, but they have no direct relationship to OS processes, as they run atop the Erlang VM) and message passing, and OTP is a framework that helps to manage the processes by specifying the relationships between the different parts of the system (eg that worker pool depends on a master process) and easily specifying how to deal with repeated failures and in-the-fly code updates, for example.
So, yesterday I had the idea: is it possible to have an OTP-like framework with Ractors? Some random thoughts about it:
Pid equivalent in Ractors; the object created by Ractor.new is needed to do a send (via Ractor#send)link/1 or monitor/2 that automatically creates a way to be informed of errors from the linked Actor, which means that it may be harder to have a reliable supervision tree like in OTPbehaviour mechanism in Erlang is incredible (more info), and I’m not aware of a better way to glue together an interface used for callbacks and the implementation of the framework. I think modules/mixins in Ruby will have to do.