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

[Sharas]

"A "stop all nodes, send code to all nodes, restart all nodes" solution is
easy to implement and pretty foolproof."

Where did 9 9ines availability with erlang go then? If you have to stop nodes.

How do you do code changes without stopping all nodes? 

The bit that inspired my about erlang is ability to deploy your code in small batches and evolve your system as you learn. Mashes well with "let it crash" in my understanding: Let it crash, as in don't try to predict what will go wrong, learn from things going wrong, and adapt (change code) fast.


On September 2, 2016 10:45:12 AM EDT, Joe Armstrong <erlang@REDACTED> wrote:
>I posted some information about why things are as they are:
>
>http://erlang.org/pipermail/erlang-questions/2016-July/089809.html
>
>The reason is historical - In the first distributed erlang all nodes
>accessed a common file store - this is no longer true when the nodes
>have separated stores.
>
>"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. If the code is in more than two versions or
>changing in different places in the system at the same time this sould
>be very tricky.
>
>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.
>
>/Joe
>
>On Fri, Sep 2, 2016 at 9:09 AM, Matthias Lang <matthias@REDACTED>
>wrote:
>> Hi,
>>
>> Thanks Nathaniel for pointing out that this is a dupe of a
>> stackoverflow question. It's good form to indicate when you're
>> aware of previous discussion and, perhaps, why you're not satisifed.
>>
>> My guess is OP isn't satisifed because
>>
>>   a) The two top-voted stack overflow answers gloss over the
>>      difference between funs defined in the shell and funs
>>      defined in code.
>>
>>   b) Neither of the top-voted answers deals with the question the
>>      OP opens with.
>>
>> Kresten's blog post, which is linked from the stack overflow
>comments,
>> is good, but it causes confusion for people who don't read it
>> carefully. One source of confusion is that it gives an example of a
>> fun which _does_ include the definition, says that the definition
>> isn't included and then, seven paragraphs later, explains that the
>> first example did actually include the definition.
>>
>> Similarly, Joe has a blog post which was up on Hacker News (again?)
>> just a few days ago with an example which borders on being overly
>cute:
>>
>>   http://joearms.github.io/2013/11/21/My-favorite-erlang-program.html
>>
>> this similarly creates the impression that all you have to do is send
>> a fun to server and you're done, not even giving a nod to the problem
>> that you need to get the code to all 1171 nodes he wants to run the
>> code on.
>>
>> ---
>>
>>
>> I'd like to wrap up with a proper answer, the sort that Richard
>> Carlsson might write, but I don't have time for that. It would:
>>
>>   - cover the difference between funs defined in the shell, funs
>which
>>     contain actual code and/or variables and funs which are pure
>>     references, e.g. fun io:fwrite/2
>>
>>   - comment on the OP's mis-use of the word "definition" and cleaning
>>     up other language sloppiness to avoid disagreements and confusion
>>     caused by misunderstanding.
>>
>>   - talk about how it's nice that the concept of funs is the same
>across
>>     lots of different uses, i.e. passing to lists:filter/2, sending
>>     to a local process, sending to a remote process and spawning, and
>>     that the cost of getting a fairly harmless surprise or two in the
>>     distributed case is low compared to the benefit of the concept
>being
>>     so simple.
>>
>>   - speculate on the possibility of an Erlang system which
>>     automaticaly distributes code when you send a fun. It seems
>>     possible, the fun includes information about where it came from.
>>
>>     My guess is that there's a simple, sane, useful case of
>>     distributed Erlang, which the case where you make sure all nodes
>>     have the same code from the start.
>>
>>     Then there's the case where nodes don't all have the same code,
>>     and that case is messy and complicated. There are problems such
>as
>>     "what do you do if the fun refers to a different version of a
>module
>>     which is already loaded on the receiving node?". This feels like
>>     research, not "getting things done", and I'm into the latter.
>>
>> Matthias
>>
>>
>----------------------------------------------------------------------
>>
>> Date: 01. September 2016
>> From: nesvarbu Pavarde <perkrovos@REDACTED>
>> To erlang-questions@REDACTED
>> Subject: [erlang-questions] What is the point of Spawn(Node, Fun) if
>Node has to have the same module loadable as a client node?
>>
>>
>>> Why create illusion that you are sending a Fun to remote node to
>execute in
>>> a new process? If client node has to have same module loadable with
>the Fun
>>> defined as a server node anyway. Why not only spawn(Node, M, F, A)
>then,
>>> which makes it clear that you are sending a definition of a function
>call,
>>> not Fun itself.
>>> I am experimenting with distributed Erlang and want it to pass
>clojures
>>> around "willy nilly", even through network. "Code is data" kinda
>thing.
>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160907/994c215b/attachment.htm>