5 ms·

Yes. Erlang probably bears out the actor model best, although there are many library implementations in various languages.

by pgt 7y ago

dnautics 7y ago
Yes and no. Carl hewit will tell you that erlang's actor model is not pure (and to be sure a process doesn't have to be much of an actor - like Elixir's Task module). But I think that impurity is one of the strengths of the BEAM. So I would qualify 'best' to meant "easiest system that 95% looks like actors that you can quickly get up and running and doing useful things and or play around with"
- anaphor 7y ago
  E (http://erights.org/ http://erights.org/), Monte (https://www.monte-language.org/ https://www.monte-language.org/), and Pony (https://www.ponylang.io/ https://www.ponylang.io/) are probably the most faithful actor-model languages I know of.
  - ProfHewitt 7y ago
    Above are important contributions, but they don't provide an adequate foundation for Actor massive concurrency.
    - dualogy 7y ago
      Any others around today that do?
      - ProfHewitt 7y ago
        The Actor Model has been used in many important large applications [Bernstein, Bykov, Geller, Kliot, and Thelin 2014; Bonér and Reisz 2017, Cesarini 2019] and has become the foundation for current computing. Satisfactory implementation for Reusable Scalable Intelligent Systems with millions of Actor cores for quadrillions of Actor are under development, but not yet publicly available.
      - dnautics 7y ago
        In erlang based systems stateful network protocols and concurrent user stories are all modeled with actors and one million connections per node for websockets is a thing. I deployed an actor-based system model to completely rearchitect and replace an inefficient stateless python system. There have been zero runtime or concurrency errors since I deployed (unfortunately sometimes the hardware the actors are modeling fail us) but patches to work around the hardware failures are simple.
ProfHewitt 7y ago
Erlang made important contributions. However, the Erlang model needs the following important extensions: •Automatically reclamation of storage of an unreachable future [Baker and Hewitt 1977] (e.g. process in Erlang). For example, an Erlang process can be orphaned if its Process Identifier (PID) becomes inaccessible. Also, since Erlang is not strongly typed, cyberattacks can be launched against dangling references to processes that no longer exist. •Language support for holes in the region of mutual exclusion of an Actor implementation. For example, in Erlang it is necessary for application programmers to explicitly code a message handler for each re-entry into the region of mutual exclusion potentially enabling cyberattacks from outside the process.
- toast0 7y ago
  Given that a PID can be sent to another node and even serialized and deserialized, it doesn't seem possible to know if it's still referenced in a meaningful way. For example, if process X on node A sends a message to process Y on node B and the network goes down, that doesn't mean process Y won't send a message to process X when the network resume.
  - ProfHewitt 7y ago
    Thanks Toast! You have made the point exactly. The problem of dangling processes is made worse by the fact that Erlang is not strongly typed.
    - imoldtoo 7y ago
      This can be mitigated by processes not being "objects". Especially objects that need to be pinned by ref counting. My personal interpretation of the Actor model is a message passing system to model the real world. In the real world I can shout out "make me a sandwich" and even if I perceive that there is a process that could potentially satisfy that request, I also work on the assumption that for any number of reasons... the channel of communication going away, misenterpretation, the agent or myself dying, the resources not being available or delays due to manufacturing may impede progress. That is just the way the real world works. Although Future/Promise can be built easily on top of Actor, they are optimistic at best - especially in diatributed cases; which, if my interpretation is correct is your reason for Actor in the first place. Actor is powerful so in my opinion, future/promise and building ref-counts on top undermines the core of it. Pat Helland, after numerous years of distributed transaction work completely did a 180 in the face of reality. There is nothing wrong with Actor. As far as strong typing, I personally believe that is a completely orthogonal conversation. I just cannot see the conflation. Strongly typed to me means I send an argument to a function and it happens to match the signature. Well, if I have a strongly typed function that takes two integers and somehow is supposed to return the sum. I guess it is helpful to know that as the user-agent (caller) of the function, but that knowledge only helps programmers, not computers. Strong typing is definitely not a model of reality when dealing with humans as functions, and often humans are end-point "processes" (heh) of function calls. Not that I am against strong typing in any way. I just believe the Actor model is cleaner without mixing things up. Certainly agree Erlang is great but not the ultimate. Well... my 2c and thanks to you, Alan, Joe, Hoare, Sussman, Gelernter et al. et al. for the inspirations over the years, and appreciate you plugging away at the models to this day. Have a wonderful holiday.

Yes. Erlang probably bears out the actor model best, although there are many library implementations in various languages.

by pgt 7y ago

Yes. Erlang probably bears out the actor model best, although there are many library implementations in various languages.

dnautics 7y ago

Yes and no. Carl hewit will tell you that erlang's actor model is not pure (and to be sure a process doesn't have to be much of an actor - like Elixir's Task module). But I think that impurity is one of the strengths of the BEAM. So I would qualify 'best' to meant "easiest system that 95% looks like actors that you can quickly get up and running and doing useful things and or play around with"

anaphor 7y ago
E (http://erights.org/ http://erights.org/), Monte (https://www.monte-language.org/ https://www.monte-language.org/), and Pony (https://www.ponylang.io/ https://www.ponylang.io/) are probably the most faithful actor-model languages I know of.
- ProfHewitt 7y ago
  Above are important contributions, but they don't provide an adequate foundation for Actor massive concurrency.
  - dualogy 7y ago
    Any others around today that do?
    - ProfHewitt 7y ago
      The Actor Model has been used in many important large applications [Bernstein, Bykov, Geller, Kliot, and Thelin 2014; Bonér and Reisz 2017, Cesarini 2019] and has become the foundation for current computing. Satisfactory implementation for Reusable Scalable Intelligent Systems with millions of Actor cores for quadrillions of Actor are under development, but not yet publicly available.
    - dnautics 7y ago
      In erlang based systems stateful network protocols and concurrent user stories are all modeled with actors and one million connections per node for websockets is a thing. I deployed an actor-based system model to completely rearchitect and replace an inefficient stateless python system. There have been zero runtime or concurrency errors since I deployed (unfortunately sometimes the hardware the actors are modeling fail us) but patches to work around the hardware failures are simple.

ProfHewitt 7y ago

Erlang made important contributions. However, the Erlang model needs the following important extensions: •Automatically reclamation of storage of an unreachable future [Baker and Hewitt 1977] (e.g. process in Erlang). For example, an Erlang process can be orphaned if its Process Identifier (PID) becomes inaccessible. Also, since Erlang is not strongly typed, cyberattacks can be launched against dangling references to processes that no longer exist. •Language support for holes in the region of mutual exclusion of an Actor implementation. For example, in Erlang it is necessary for application programmers to explicitly code a message handler for each re-entry into the region of mutual exclusion potentially enabling cyberattacks from outside the process.

toast0 7y ago
Given that a PID can be sent to another node and even serialized and deserialized, it doesn't seem possible to know if it's still referenced in a meaningful way. For example, if process X on node A sends a message to process Y on node B and the network goes down, that doesn't mean process Y won't send a message to process X when the network resume.
- ProfHewitt 7y ago
  Thanks Toast! You have made the point exactly. The problem of dangling processes is made worse by the fact that Erlang is not strongly typed.
  - imoldtoo 7y ago
    This can be mitigated by processes not being "objects". Especially objects that need to be pinned by ref counting. My personal interpretation of the Actor model is a message passing system to model the real world. In the real world I can shout out "make me a sandwich" and even if I perceive that there is a process that could potentially satisfy that request, I also work on the assumption that for any number of reasons... the channel of communication going away, misenterpretation, the agent or myself dying, the resources not being available or delays due to manufacturing may impede progress. That is just the way the real world works. Although Future/Promise can be built easily on top of Actor, they are optimistic at best - especially in diatributed cases; which, if my interpretation is correct is your reason for Actor in the first place. Actor is powerful so in my opinion, future/promise and building ref-counts on top undermines the core of it. Pat Helland, after numerous years of distributed transaction work completely did a 180 in the face of reality. There is nothing wrong with Actor. As far as strong typing, I personally believe that is a completely orthogonal conversation. I just cannot see the conflation. Strongly typed to me means I send an argument to a function and it happens to match the signature. Well, if I have a strongly typed function that takes two integers and somehow is supposed to return the sum. I guess it is helpful to know that as the user-agent (caller) of the function, but that knowledge only helps programmers, not computers. Strong typing is definitely not a model of reality when dealing with humans as functions, and often humans are end-point "processes" (heh) of function calls. Not that I am against strong typing in any way. I just believe the Actor model is cleaner without mixing things up. Certainly agree Erlang is great but not the ultimate. Well... my 2c and thanks to you, Alan, Joe, Hoare, Sussman, Gelernter et al. et al. for the inspirations over the years, and appreciate you plugging away at the models to this day. Have a wonderful holiday.