IIRC it was a few years after the dynamo paper came out, and at a time when a bunch of other nosql+high scalability solutions did (e.g. Cassandra)
Riak the database used Riak Core, but it could be used independently of the database.
I hadn’t thought about Core in a long time, I should take another look.
Looks like someone is carrying the idea forward: https://riak-core-lite.github.io/
I had some similar issues with rabbitmq
On the other hand, Phoenix channels were much more flexible about membership
The key characteristic is not a state machine, but that:
- first class processes send messages to each other
- messages are queued
- each process is single execution flow. If you want to reenter code, start another process and send messages to it
- process execution can be preempted
- values passed in messages are for the most part, immutable.
- first class support for “links”, where one process gets notified when another process crashes (basis for supervision trees)
The consequences of this design are:
- for the most part, you don’t need mutexs
- spin locks are cheap
- every process can be suspended indefinitely when nothing is in the message queue. This is better than an async reactor.
- processes don’t get “lost” (I am looking at you, Nodejs)
- processes can receive control messages to suspend or shutdown, restart, etc. Most other platforms have to externalize that to say, K8S and such controls are crude.
- errors don’t get “lost” (Nodejs again …)
- repl in production, can inspect the whole system live, under load
- overloaded systems degrades gracefully instead of locking up
Looks like I misread it. While the Actor model was conceived before Erlang, the Erlang actor model was developed in parallel. It isn’t a pure implementation of Actors (everything is an Actor, making it closer fo Smalltalk). Only processes are Actors. It also implies that Akka is not a true Actor model as conceived in the originao ‘73 paper.
This goes into greater detail on the history: https://www.labouseur.com/courses/erlang/history-of-erlang-a...
In any case, there are not many contemporary systems that uses these ideas.
However, I just consider some things in the world outside of Elixir/Erlang/BEAM to be a bit more common. For example, using Docker with Kubernetes/ECS/etc as a deployment story. Or connecting micro-services using REST/gRPC/GraphQL. Or using queue systems like SQS or Kafka (to be fair, literally yesterday an ElixirConf talk about using Kafka with Elixir was posted). The advantage of BEAM is that you can avoid that stuff in some cases because it is built in to the platform - but that is a double edged sword since now you aren't doing those things.
Even if I have used Akka for Actors in Scala/Java/Kotlin, something about the BEAM based languages still feels like I am stepping onto the Galapagos Islands and seeing a ecosystem that has been evolving in its own isolation for decades. Sure, there are birds, but they just don't look like any birds I've seen before.
Stuff like LiveView though looks like magic because it is magic. There are a lot of moving parts involved in getting it working. It’s the result of work that has been going on for the past decade across multiple communities though. The ideas are mature even if there is a lot of abstraction.
Stuff like Riak was well ahead of its time. They basically had the idea of being able to create robust distributed systems much the same way you would a GenServer.