We understand concurrencyA deep understanding of concurrency is hard-wired into our brains. We react to stimulation extremely quickly, in a part of the brain called the amygdala, without this reaction system we would die. Conscious thought is just too slow, by the time the thought "hit the brakes" has formed itself, we have already done it.
On a motorway, I mentally track the positions of dozens, or hundreds of cars, this is done without conscious thought. If I couldn't do this I would probably be dead.
The world is parallel
If we wish to write programs that behave as other objects behave in the real world then these programs will have a concurrent structure.
This is why we should program in a concurrent programming language
And yet most often we program real-world applications in sequential programming languages. This is uncessarily difficult.
By programming in a language what was designed for programming concurrent applications (like Erlang) concurrent programming becomes a lot easier.
Erlang programs model how we think and interact
We don't have shared memory. I have my memory, you have yours, we have two brains, one each, they are not joined together. To change your memory I send you a message, I talk or wave my arms. You listen, you see, your memory changes, but without asking you a question or observing your response I do not know that you have received my messages.
This is how it is with Erlang processes. Erlang processes have no shared memory. Each processes has its own memory. To change the memory of some other process you must send it a message and hope that it receives and understands the message.
To confirm that another process has received your message and changed its memory, you must ask it (by sending it a message). This is exactly how we interact.
Sue: "Hi Bill, my telephone number is 45 67 89 12"
This is how it is with Erlang processes. Erlang processes have no shared memory. Each processes has its own memory. To change the memory of some other process you must send it a message and hope that it receives and understands the message.
To confirm that another process has received your message and changed its memory, you must ask it (by sending it a message). This is exactly how we interact.
Sue: "Hi Bill, my telephone number is 45 67 89 12"
Sue: "Did you hear me?"
Bill: "sure, your number is 45 67 89 12"
These interaction patterns well-know to us, from birth onwards we learn to interact with the world by observing it and by sending it messages and observing the responses.
People function as independent entities that communicate by sending messages
That's how Erlang processes work, and that's how we work so it's very easy to understand an Erlang program.
Erlang programs are made up of lots of little processes all chattering away to each other - just like people.
Erlang programs are made up of lots of little processes all chattering away to each other - just like people.
An Erlang program is made up of dozens, possible thousands or even hundreds of thousands of small processes - all these processes operate independently. They communicate with each other by sending messages. Each process has a private memory. They behave like a huge room of people all chattering away to each other.
This makes Erlang program inherently easy to manage and scale. Suppose we have ten people (processes) and they have too much work to do, what can we do? get more people. How can we manage these groups of people, easy just shout instructions at them (broadcasting).
Erlang processes don't have shared memory, so there is no need to lock the memory while it is being used. Where there are locks, there are keys, and when there are keys the keys will one day get lost and what happens when you loose a key? - you panic.
Distributed software systems with locks and keys always go wrong.
If somebody dies other people will notice
I I'm in a room and suddenly keel over and die, somebody will probably notice, well at least I hope so. Erlang processes are just like people, they can on occasions die. Unlike people when they die they shout out in their last breath exactly what they have died from.
Imagine a room full of people, suddenly one person will keel over and die and just as they die, they say "I'm dying of a heart attack" or "I'm dying of an exploded gastric wobbledgog". That's what Erlang processes do. One process might die saying.
"I'm dying because I was asked to divide by zero", another might say
"I'm dying because because I was asked what the last element in an empty list was"
Now in our room full of people we might imagine there are specially assigned people whose job it is to clear away the bodies. Let's imagine two people Jane and John. If Jane dies then John will fix any problems associated with Jane's death. If Jane dies then John will fix the problems. Jane and John are linked together with an invisible agreement which says that if one of them dies the other will fix up any problems caused by the death.
That's is how error detection in Erlang works, processes can be linked together. If one of the processes dies, the other process gets an error message saying why the first process dies.
That's basically it.
That's how Erlang programs work.
What we've learnt so far
Erlang programs are made of lots of processes. These processes can send messages to each other.
These message may or may not be received and understood. If you want to know if a message was received and understood you must send the process a message and wait for a reply.
Pairs of processes can be linked together. If one processes in a linked pair dies the other process in the pair will be sent a message containing the reason why the first process died.
This simple model of programming is part of a model I call Concurrency Oriented Programming. You can read more about this here.
