~mrlee/www.kamelasa.dev

196935d00ec1d6aaac9d92b800732cce6bcf5e5a — Lee Meichin 2 months ago 35741ef
Elaborate on examples
1 files changed, 4 insertions(+), 0 deletions(-)

M posts/ruby-sorcery-ractor.poly.pm
M posts/ruby-sorcery-ractor.poly.pm => posts/ruby-sorcery-ractor.poly.pm +4 -0
@@ 42,6 42,10 @@ In Erlang/Elixir, one key feature is that programs are designed to be fault-tole

You can consider technologies like Kubernetes◊^[7], Kafka◊^[8], and Web Workers◊^[9] in the browser to each be an application of the actor model in some form. This doesn't necessarily mean they were built with that in mind, just that you can find that they share many characteristics in common.

For example, in Kubernetes (K8S), the orchestrator is an actor that behaves as a supervisor. It is responsible for monitoring all of the other services that are deployed in the cluster and ensuring that they're kept alive. If a service goes down, it will attempt to reboot it. The service is also an actor, as it can talk to other services. It can change its own state (e.g. in-memory or with a database), but it cannot (or should not) reach into other services to do the same.

Kafka offers three concepts of an actor: a producer, which is an actor that can only send messages; a consumer, which is an actor that can only receive messages ◊em{but also} create a producer to send messages; and a broker, which acts as a storage layer as well as a supervisor of sorts.

Similarly, an email inbox is another application of the pattern. Your email inbox is attached to one or more email addresses (or aliases), and messages that are meant for you are sent to your address (or many at once). Eventually, they will arrive in your inbox and you can then read the email and decide to archive it, delete it, report it as spam, and so on. This is also the case for a mailing list, where messages sent to the mailing list's address will eventually be distributed to every subscriber's address.

◊h1{Ractor}