I would have liked the discussion about Raft/Paxos that they said they'd leave out of this episode though :(
Facebook's LogDevice had a similar sequencer component too https://engineering.fb.com/2017/08/31/core-data/logdevice-a-...
Disclosure: I work on FaunaDB.
Whenever one comes up, the other is likely to be mentioned close at hand:
Continuous, minor improvements over time (just like Clojure). Nothing too groundbreaking lately AFAIK, but still worthy to use if you have the use cases for it. Changelog can be found here: https://docs.datomic.com/on-prem/changes.html
Some of the cool kids in Clojure world seem to have moved over to XTDB these days.
[0] https://lmax-exchange.github.io/disruptor/ [1] https://github.com/real-logic/aeron
We are using it right now as the foundation for a new business administration platform.
It's even more ridiculous in .NET due to enhancements relative to value types:
https://medium.com/@ocoanet/improving-net-disruptor-performa...
In .NET6, this is potentially one of the fastest ways to serialize an arbitrary # of threads.
The Bitcoin blockchain is just a list of transactions, the hard part is getting everybody to agree on which transactions happened and which order they happened in. Once that happens everybody can run all the transactions in order to figure out what the current state is. The bitcoin state is mostly implicit. In order to figure out the current set of balances you have to run every transaction.
Actors usually refers to a scheme with multiple coroutines which communicate via message passing. The emphasis is on the fact that there is no shared state: all communication happens via message passing. It's usually something which comes up in programming language design.
State Machine Replication usually refers to a scheme where all operations are serialized to a log and have a completely deterministic result, allowing you to reach the same state on any other machine simply by replaying the log. The emphasis is on existence of that persistence log, and on the deterministic result of applying it. It's usually something which comes up in distributed systems. It's also a common pattern in databases though it's usually just called "replication".
Erlang is the classic actor model example. Most erlang deployments do not keep persistent logs of messages. There are "inbox"es but those are transient and message disappear as soon as they are processed, actors are also not required to have deterministic responses to incoming messages. So, most erlang programs do not resemble state machine replication!
The classic example of SMR is something like Postgres streaming replication. One machine saves all changes to a log before it commits any transactions, and another machine is continuously processing that log. This gives you two instances of the database, making it easy to switch over to the second machine if the first one ever fails. This kind of looks like actors, if you squint, but usually when we talk about actors we don't think of each of the processes running on each of our machines as actors.
