5 ms·

You are overthinking some of it at least when it comes to concurrency. Look at what a process is and how send works. GenServer is a natural generalization of a

by jb3689 3y ago

You are overthinking some of it at least when it comes to concurrency. Look at what a process is and how send works. GenServer is a natural generalization of a pattern you’d write a thousand times. Knowledge of actors is transferable. Go has libraries which implement actor abstractions for example. Process mailboxes are just message queues like Go’s channels are. There are differences with respect to how the interpreters work and how processor yields work. 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.

riffraff 3y ago
Why do you think riak was well ahead of its time? (actual question, I'm not arguing) 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)
- macintux 3y ago
  I suspect the parent comment is primarily referring to Riak Core, which was another layer of abstraction above Erlang’s OTP for distributed processing. 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/ https://riak-core-lite.github.io/
  - riffraff 3y ago
    Ah that makes sense, thank you.
baq 3y ago
Riak was pretty bad at ops. Leaving and joining nodes took ages and god forbid you tried to use any of the added features like solr search. If you settled on a very small subset of all features it worked nicely... it just wasn't very useful if anything went wrong due to app or user error.
- hosh 3y ago
  I think that was before things like raft or paxos I had some similar issues with rabbitmq On the other hand, Phoenix channels were much more flexible about membership
brandensilva 3y ago
I was gonna say the actor model stems from state machines I believe. It's a nice way to manage state and communication. It reminds me of supervisors and processes in general but not program language specific.
- hosh 3y ago
  Erlang developed the way it did before people started calling it an Actor model. 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
  - az09mugen 3y ago
    Erlang did appear after the creation of the actor model. The actor model is from 1973 : https://en.m.wikipedia.org/wiki/Actor_model https://en.m.wikipedia.org/wiki/Actor_model And Erlang is from 1987 : https://fr.m.wikipedia.org/wiki/Erlang_%28langage%29 https://fr.m.wikipedia.org/wiki/Erlang_%28langage%29
    - hosh 3y ago
      https://softwareengineering.stackexchange.com/a/277469 https://softwareengineering.stackexchange.com/a/277469 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-armstrong.pdf https://www.labouseur.com/courses/erlang/history-of-erlang-a... In any case, there are not many contemporary systems that uses these ideas.
zoogeny 3y ago
I have no trouble understanding the concepts, its the nomenclature that is different. It is the same with Haskell or other niche languages - once you are familiar with the terminology then you start to feel comfortable. 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.

by jb3689 3y ago

riffraff 3y ago

Why do you think riak was well ahead of its time? (actual question, I'm not arguing) 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)

macintux 3y ago
I suspect the parent comment is primarily referring to Riak Core, which was another layer of abstraction above Erlang’s OTP for distributed processing. 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/ https://riak-core-lite.github.io/
- riffraff 3y ago
  Ah that makes sense, thank you.

baq 3y ago

Riak was pretty bad at ops. Leaving and joining nodes took ages and god forbid you tried to use any of the added features like solr search. If you settled on a very small subset of all features it worked nicely... it just wasn't very useful if anything went wrong due to app or user error.

hosh 3y ago
I think that was before things like raft or paxos I had some similar issues with rabbitmq On the other hand, Phoenix channels were much more flexible about membership

brandensilva 3y ago

I was gonna say the actor model stems from state machines I believe. It's a nice way to manage state and communication. It reminds me of supervisors and processes in general but not program language specific.

hosh 3y ago
Erlang developed the way it did before people started calling it an Actor model. 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
- az09mugen 3y ago
  Erlang did appear after the creation of the actor model. The actor model is from 1973 : https://en.m.wikipedia.org/wiki/Actor_model https://en.m.wikipedia.org/wiki/Actor_model And Erlang is from 1987 : https://fr.m.wikipedia.org/wiki/Erlang_%28langage%29 https://fr.m.wikipedia.org/wiki/Erlang_%28langage%29
  - hosh 3y ago
    https://softwareengineering.stackexchange.com/a/277469 https://softwareengineering.stackexchange.com/a/277469 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-armstrong.pdf https://www.labouseur.com/courses/erlang/history-of-erlang-a... In any case, there are not many contemporary systems that uses these ideas.

zoogeny 3y ago

I have no trouble understanding the concepts, its the nomenclature that is different. It is the same with Haskell or other niche languages - once you are familiar with the terminology then you start to feel comfortable. 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.