6 ms·

The biggest question I have about this: Is it really a good idea to make local actors and supervisor trees indistinguishable from remote ones? Reusability is g

The biggest question I have about this: Is it really a good idea to make local actors and supervisor trees indistinguishable from remote ones? Reusability is good. Abstractions that are so "good" that they obscure potentially order-of-mag performance differences -- I'm not sold. Whether an actor is in-memory with me or across a TCP socket is order-of-mag, and may make the difference between whether my program satisfies is service goals, or fails them abjectly. Especially if that randomized latency happens a number of times, or in unpredictable places. Error handling paths that have to account for the Two-Generals problem being indistinguishable from local errors I can be confident I'll hear about -- I'm not sold on that, either. I'd be interested to hear rebuttals to those from folks who have worked deeply with OTP. Is it just... not that bad, in practice? Or are there parts of the abstraction that specifically help counter these concerns?

pyotrgalois 10y ago
In some way this article by one of Erlang creators is related to your comment: https://armstrongonsoftware.blogspot.com.ar/2008/05/road-we-didnt-go-down.html https://armstrongonsoftware.blogspot.com.ar/2008/05/road-we-... > The fundamental problem with taking a remote operation and wrapping it up so that it looks like a local operation is that the failure modes of local and remote operations are completely different.
- qznc 10y ago
  Armstrong clearly sees the problem. I understand his solution as: Erlang makes local and remote actors indistinguishable, but you should build your own custom wrapper for remote calls. This seems fishy to me. You build low-level boilerplate over a high-level foundation? To clarify, I consider implementing the timeout as "low-level" and a mechanism like "link(remote_process)" as "high-level".
  - pyotrgalois 10y ago
    Could you please explain why do you think a timeout would be low level?
- derefr 10y ago
  I think of Erlang less as making remote operations masquerade as local ones, and more as forcing you to assume that all local code has the potential failure-modes of remote code. Which, often (for weird and roundabout reasons) it does.
  - jeffdavis 10y ago
    Very insightful!
  - im_down_w_otp 10y ago
    This.
abecedarius 10y ago
You want two kinds of abstractions: ones that can only run locally, and ones that may be remote. For the remote kind it should be easy and transparent to run them locally. In Erlang these are function calls vs. message sending. Some other languages like E also make that kind of distinction. I believe the bad rep of network transparency came from experience trying to cross the line in the other direction: trying to pretend remote services are local.
toast0 10y ago
> The biggest question I have about this: Is it really a good idea to make local actors and supervisor trees indistinguishable from remote ones? The erlang code to send a message to a remote pid and a local pid is the same, but that doesn't make them indistinguishable; you can check if the pid is local or not in code. In my experience, I have some expectations of where the thing I'm messaging is going to be when I write the code, and I can act accordingly: better error handling when I expect to talk to a remote node since I can't be sure I'll be able to reach it; whereas if I expect to reach a local pid, I'm more likely to match against success and let it crash if something weird happened.

pyotrgalois 10y ago

In some way this article by one of Erlang creators is related to your comment: https://armstrongonsoftware.blogspot.com.ar/2008/05/road-we-didnt-go-down.html https://armstrongonsoftware.blogspot.com.ar/2008/05/road-we-... > The fundamental problem with taking a remote operation and wrapping it up so that it looks like a local operation is that the failure modes of local and remote operations are completely different.

qznc 10y ago
Armstrong clearly sees the problem. I understand his solution as: Erlang makes local and remote actors indistinguishable, but you should build your own custom wrapper for remote calls. This seems fishy to me. You build low-level boilerplate over a high-level foundation? To clarify, I consider implementing the timeout as "low-level" and a mechanism like "link(remote_process)" as "high-level".
- pyotrgalois 10y ago
  Could you please explain why do you think a timeout would be low level?
derefr 10y ago
I think of Erlang less as making remote operations masquerade as local ones, and more as forcing you to assume that all local code has the potential failure-modes of remote code. Which, often (for weird and roundabout reasons) it does.
- jeffdavis 10y ago
  Very insightful!
- im_down_w_otp 10y ago
  This.

abecedarius 10y ago

You want two kinds of abstractions: ones that can only run locally, and ones that may be remote. For the remote kind it should be easy and transparent to run them locally. In Erlang these are function calls vs. message sending. Some other languages like E also make that kind of distinction. I believe the bad rep of network transparency came from experience trying to cross the line in the other direction: trying to pretend remote services are local.

toast0 10y ago

> The biggest question I have about this: Is it really a good idea to make local actors and supervisor trees indistinguishable from remote ones? The erlang code to send a message to a remote pid and a local pid is the same, but that doesn't make them indistinguishable; you can check if the pid is local or not in code. In my experience, I have some expectations of where the thing I'm messaging is going to be when I write the code, and I can act accordingly: better error handling when I expect to talk to a remote node since I can't be sure I'll be able to reach it; whereas if I expect to reach a local pid, I'm more likely to match against success and let it crash if something weird happened.