4 ms·

how does this compare to the inbox and supervisor model of erlang/elixir?

by pmarreck 10mo ago

yetihehe 10mo ago
It doesn't. It's "promise" based, not "communicating sequential processes". Erlang has more preemptive scheduling, a "thread" can be preempted at any time, here you can only be synchronized when you wait for result. It is called "actor-based", because only functions tagged as "actor" can call waiting functions. This is more node.js-like communication than erlang.
- jacquesm 10mo ago
  By they looks of it they changed the word 'async' to 'actor' because they thought it was cool not because it actually uses the actor pattern. Which to me seems to be namespace pollution.
  - junon 10mo ago
    Unfounded guess, they probably didn't want to bump into the new C++ keywords for async/await.
  - voidmain 10mo ago
    If I were designing it today rather than in... 2008?, I would use the terms 'async' and 'await' because they are a lingua franca now. And for a modern audience that already knows what promises are it probably makes sense to start the explanation with that part. But the thing as a whole was intended to build lightweight asynchronously communicating sequential processes with private state that can be run locally or in a distributed way transparently, restarted on failure, etc. I don't think the choice of terms was obviously a crime at the time.
- thesz 10mo ago
  They build channels on top of these "promises" and "futures" and this made them square into communicating sequential processes category. Also, you can look at promise-future pair as a single-element channel, again, it's CSP. BTW, Erlang does not implement CSP fully. Its' interprocess communication is TCP based in general case and because of this is faulty.
  - yetihehe 10mo ago
    It is not TCP based. In Erlang processes have mailboxes. But they don't have promises, you send a message and wait for response with timeout or do something else. And TCP is only used between nodes (vm instances). But you can use any communication channel (UDP, unix sockets, tls, serial port, some other process doing funny things). > Its' interprocess communication is TCP based in general case and because of this is faulty. What? It's faulty because of TCP? No, in Erlang it is assumed that communication can be faulty for a lot of reasons, so you have to program to deal with that and the standard library gives you tools to deal with this.
    - thesz 10mo ago
      There is no such thing as "Communicating Sequential Processes with faulty channels and processes." I tried to find something like that, fruitlessly. This means that Erlang does not implement CSP, it implements something else. Again, general case of communication between Erlang processes includes communication between processes on different machines.
  - pmarreck 10mo ago
    > BTW, Erlang does not implement CSP fully. Specific evidence? > Its' interprocess communication is TCP based in general case No, it is not. Only between machines is that true. > and because of this is faulty. LOL, no. Why are you rolling with "speaking a whole lot of BS based on ignorance" today? On the other hand, I now understand that one impediment to Elixir adoption is apparently "people repeating a lot of bullshit misinformation about it"
    - thesz 10mo ago
      >> Its' interprocess communication is TCP based in general case > No, it is not. Only between machines is that true. It is true for communication between two VMs on same machine, isn't it? The general case includes same-VM processes, different VM processes and also different VMs on different machines. > Why are you rolling with "speaking a whole lot of BS based on ignorance" today? TCP is unreliable: https://networkengineering.stackexchange.com/questions/55581/acknowledgment-by-tcp-does-not-guarantee-that-the-data-has-been-delivered https://networkengineering.stackexchange.com/questions/55581... That was acknowledged by Erlang's developers before 2012. I remember that ICFP 2012 presentation about Cloud Haskell mentioned that "Erlang 2.0" apparently acknowledged TCP unreliability and tried to work around.
hawk_ 10mo ago
Ok a related note, how does it compare to SeaStar?

how does this compare to the inbox and supervisor model of erlang/elixir?

It doesn't. It's "promise" based, not "communicating sequential processes". Erlang has more preemptive scheduling, a "thread" can be preempted at any time, here you can only be synchronized when you wait for result. It is called "actor-based", because only functions tagged as "actor" can call waiting functions. This is more node.js-like communication than erlang.

jacquesm 10mo ago
By they looks of it they changed the word 'async' to 'actor' because they thought it was cool not because it actually uses the actor pattern. Which to me seems to be namespace pollution.
- junon 10mo ago
  Unfounded guess, they probably didn't want to bump into the new C++ keywords for async/await.
- voidmain 10mo ago
  If I were designing it today rather than in... 2008?, I would use the terms 'async' and 'await' because they are a lingua franca now. And for a modern audience that already knows what promises are it probably makes sense to start the explanation with that part. But the thing as a whole was intended to build lightweight asynchronously communicating sequential processes with private state that can be run locally or in a distributed way transparently, restarted on failure, etc. I don't think the choice of terms was obviously a crime at the time.
thesz 10mo ago
They build channels on top of these "promises" and "futures" and this made them square into communicating sequential processes category. Also, you can look at promise-future pair as a single-element channel, again, it's CSP. BTW, Erlang does not implement CSP fully. Its' interprocess communication is TCP based in general case and because of this is faulty.
- yetihehe 10mo ago
  It is not TCP based. In Erlang processes have mailboxes. But they don't have promises, you send a message and wait for response with timeout or do something else. And TCP is only used between nodes (vm instances). But you can use any communication channel (UDP, unix sockets, tls, serial port, some other process doing funny things). > Its' interprocess communication is TCP based in general case and because of this is faulty. What? It's faulty because of TCP? No, in Erlang it is assumed that communication can be faulty for a lot of reasons, so you have to program to deal with that and the standard library gives you tools to deal with this.
  - thesz 10mo ago
    There is no such thing as "Communicating Sequential Processes with faulty channels and processes." I tried to find something like that, fruitlessly. This means that Erlang does not implement CSP, it implements something else. Again, general case of communication between Erlang processes includes communication between processes on different machines.
- pmarreck 10mo ago
  > BTW, Erlang does not implement CSP fully. Specific evidence? > Its' interprocess communication is TCP based in general case No, it is not. Only between machines is that true. > and because of this is faulty. LOL, no. Why are you rolling with "speaking a whole lot of BS based on ignorance" today? On the other hand, I now understand that one impediment to Elixir adoption is apparently "people repeating a lot of bullshit misinformation about it"
  - thesz 10mo ago
    >> Its' interprocess communication is TCP based in general case > No, it is not. Only between machines is that true. It is true for communication between two VMs on same machine, isn't it? The general case includes same-VM processes, different VM processes and also different VMs on different machines. > Why are you rolling with "speaking a whole lot of BS based on ignorance" today? TCP is unreliable: https://networkengineering.stackexchange.com/questions/55581/acknowledgment-by-tcp-does-not-guarantee-that-the-data-has-been-delivered https://networkengineering.stackexchange.com/questions/55581... That was acknowledged by Erlang's developers before 2012. I remember that ICFP 2012 presentation about Cloud Haskell mentioned that "Erlang 2.0" apparently acknowledged TCP unreliability and tried to work around.

hawk_ 10mo ago

Ok a related note, how does it compare to SeaStar?