I was reading the faq of Golang where I learn that Erlang is stemmed from CSP but we know that it is based upon actor model. Does the earlier version of Erlang was based on tony hoare CSP work?
2 Likes
Just to save you time, hereās the relevant section of the Go faq:
Why build concurrency on the ideas of CSP?
Concurrency and multi-threaded programming have over time developed a reputation for difficulty. We believe this is due partly to complex designs such as pthreads and partly to overemphasis on low-level details such as mutexes, condition variables, and memory barriers. Higher-level interfaces enable much simpler code, even if there are still mutexes and such under the covers.
One of the most successful models for providing high-level linguistic support for concurrency comes from Hoareās Communicating Sequential Processes, or CSP. Occam and Erlang are two well known languages that stem from CSP. Goās concurrency primitives derive from a different part of the family tree whose main contribution is the powerful notion of channels as first class objects. Experience with several earlier languages has shown that the CSP model fits well into a procedural language framework.
[Emphasis added.]
Erlang is conceptually similar to Occam, though it recasts the ideas of CSP in a functional framework and uses asynchronous message passing instead of the synchronous message passing in CSP.
Taken from
https://cacm.acm.org/magazines/2010/9/98014-erlang/fulltext
@rvirding might be best at answering this question.
1 Like
The developers of Erlang have stated in many forums that they learned about the āActor Modelā only after having written the base Erlang system. See e.g.
https://twitter.com/rvirding/status/766241963389677568
https://twitter.com/rvirding/status/766242280592277504
5 Likes
Erlang was indirectly influenced by CSP - but the major influences were Smalltalk and Prolog. Smalltalk talked about objects and of doing things by sending messages to objects (in fact message sending in smalltalk was not true message sending but syntactic sugar for a synchronous function call).
The first Erlang was a Prolog implementation of a Smalltalk message passing model of a telephony system.
Iād always liked the idea of messaging between parallel processes as a way of separating concerns and mainly because it was the only way I could think of to make things fault tolerant - I reasoned that if the entire machine crashed the computation would have to continue on a different (linked) machine - if you have two machines the only way they can communicate is via messaging - there is actually no such thing as shared memory in distributed systems (this is a programming abstraction that cannot be created) messages are really photons bouncing up and down in a fibre or changes in an electromagnetic field and they travel at most at the speed of light.
CSP assumes lock-step synchronous communication between a sender and receiver - if a sender emits a symbol āxā and the receiver receives a symbol āxā and they are in phase then we can step both the sender and the receiver. So with CSP you can prove things about protocols in an algebraic sence.
While I liked the CSP model (and notation) I didnāt like the assumptions of synchronicity.
It seems to me that you can either have:
a) A mathematically sound system where you can prove things - but you can never build since you break laws of physics.
or
b) A physically sound system that breaks no laws of physics, but which we cannot know the correctness of.
a) is CSP - we can prove CSP specifications to be sound but we cannot implement them since things like delivery of messages can never be proven.
b) is Erlang - we make no assumptions about message delivery other that what we observe. If we want to guarantee that a process has received a message we must add a unique tag and do a round trip and check we get the message back again. If the message does not come back we wonāt know why - it might be a remote failure or a communication failure. We canāt prove that remote systems are alive NOW only make statements about the fact that we knew the remote system was alive the last time it told us.
Seems like there is a dichotomy - system building is a trade off between what we can build and what we can prove. We can build systems whoes properties we cannot prove - and we can prove properties about systems that we cannot build.
29 Likes
I am convinced that there is some fundamental law of distributed systems in there. Something more fundamental and important than the CAP Theorem, also even more important to communicate to programmers in that field. For example, it sums up pretty well why trying to emulate local objects in RPC systems does not work, the extra failure modes you get when doing remote calls being that part you cannot prove.
1 Like
