[erlang-questions] What is the point of Spawn(Node, Fun) if Node has to have the same module loadable as a client node?

[Richard A. O'Keefe]

On 3/09/16 2:45 AM, Joe Armstrong wrote:
>
> "All you have to do" (TM) is make sure all nodes have the same
> code before sending funs around. This is not easy in the general case,
> since all the code the fun calls also needs to be copied, and all the
> code it calls and so on.

This could of course be done lazily, but that would (probably)
lead to unexpected and quite long delays later on, which is a
Bad Thing in a "soft real time" language.

This may be the best reason for not even trying to do it
(lazily OR eagerly).  When you send a message to another node,
you'd like to have some idea of how much you're sending and
(in very rough terms) how long it's likely to take, but quite
a small fun might drag in quite a lot of dependencies, or not,
depending on how much code the sender and receiver already
share.

Something of the sort *can* be done.  Kali Scheme used to
let you send code around.  Someone seems to be trying to
revive it: http://community.schemewiki.org/kali-scheme/
http://community.schemewiki.org/?kali-scheme-revival

In order to make something like this work, I think we really
need something like Chris Brown's ideas for SafeErlang, a
scheme in which multiple versions of modules can co-exist
without confusion.

> A "stop all nodes, send code to all nodes, restart all nodes" solution is
> easy to implement and pretty foolproof.
>
> Not elegant but it gets the job done.

I'm not sure that it's all that inelegant.
You pay the price when you *expect* to pay the price,
and you can check that the "upgrade" will land you in
a sensible state before you make any change..


There is of course another possibility.
If you need to send "pieces of behaviour" to another node,
you can define a mini-language represented as Erlang
data structures as part of the protocol, and send something
over that is a *scrutable* data structure in which general
Bad Things simply aren't expressible, and that can be
interpreted or compiled to Erlang by the receiver as it
chooses.  "Stuff we can run" doesn't have to be Erlang
any more than it has to be ARM assembly code.