3 ms·
Anything concurrent and distributed you want supported by your runtime a la Erlang. The reason is: you want certain guarantees. For example, in Erlang you can
by dmitriid 5y ago
Anything concurrent and distributed you want supported by your runtime a la Erlang.
The reason is: you want certain guarantees. For example, in Erlang you can set up a monitor on a process, and when that process exits for any reason, you get a notification, {EXIT, Reason}. Even if that reason was a catastrophic failure of some sort.
If this is implemented as a library, then the runtime can kill your code at any time, and you'll never know what happened.
- ProfHewitt 5y agoErlang has absolutely no security :-(
- fulafel 5y agoSo what kind of security does this have? The article doesn't mention the term.
- acjohnson55 5y agoI don't know if that's true. In the Scala and Java worlds, a library called Akka provides distributed actors as a library. As far as I know, what you describe isn't a limitation. See https://doc.akka.io/docs/akka/2.5.32/general/supervision.html#what-lifecycle-monitoring-means https://doc.akka.io/docs/akka/2.5.32/general/supervision.htm...
- dmitriid 5y agoIt is a limitation. If the VM on the other machine is killed, or kills the thread, you'll never know that happened, and why. Well, you can probably ping the process and what not :) Compare Erlang's error handling and monitors: https://erlang.org/doc/reference_manual/processes.html#error-handling https://erlang.org/doc/reference_manual/processes.html#error...
- acjohnson55 5y agoI would assume Erlang is doing some type of heartbeat at the runtime level. You can always do this in your protocol if you absolutely need to. I know that in Akka Cluster, you configure this to set the rules for a node to be considered alive in the cluster, and if it's dead, all the actors hosted on it will be considered dead, too. In a distributed system, I'm pretty certain you cannot guarantee receipt of an expected message, no matter what you try to do.