"Erlang based systems obtain many of the aforementioned properties from the Erlang concurrency model. Erlang handles the concurrency itself instead of relying on the OS. A concurrent entity in Erlang, called Erlang process, is much lighter than a standard OS process or thread, initially using about 3 KB of memory on a 64bit system. In a typical Erlang systems, you can easily create hundreds of thousands or maybe even millions of Erlang processes. The Erlang virtual machine uses its own scheduler which ensures that each process gets a fair share of execution time. The scheduler also distributes processes over available CPU cores, using as few OS threads as possible (by default only as much as the number of available CPU cores)."
It is kind of like Node in that it is very easy to do concurrent stuff, except instead of nested callbacks and all that jazz, you write 'processes' which are designed to share nothing. They run akin to OS threads in that one process crashing won't bring down the whole system (unlike Node). As no state is shared it also means that they can easily (i.e. it is built into the VM, and switched on by default) be scaled up to run over many cores. If you are interested, you might want to look at Elixir (a language built on top of the Erlang VM) which has a more Ruby-esque syntax: http://elixir-lang.org/
EDIT: Should also point out that I think "Jessica's" comment was just trolling, however it isn't far from the truth :)
Is ``Jessica's'' comment not far from the truth because Scala and Go have shared memory for their Actors/Processes? I know Erlang doesn't share memory between their processes which leads to concurrency; is this what she was getting at?
In general (apart from run time code loading) one can accomplish a lot of things Erlang does in any language.
Her "how much pain and when" I think implies that she only accepts concurrency as practical when units of concurrency are isolated as that would reduce the number of shared data structures being updated, lock contentions and so on. There is some truth in there that I agree with.
But then again maybe she was just trolling. I for one do not like her tone her comment.
Good question. Hopefully you have not been put off by that comment. It comes off kind of harsh.
She wasn't right about lack of concurrency. Go, Scala, Python, hell all of them I guess can do "concurrency". They all have facilities to launch concurrent requests/actors/callback threads/other processes.
Now maybe what she was going to say (and her "how much pain and when" kind of hints in that direction) is that once you start handling large scale concurrency, things get very complicated. Anything that lets you share memory will eventually bite you back in terms of debugging and downtime.
Erlang's concurrency is unique because its concurrency units are isolated. They are as isolated as possible. Each has its own memory. Garbage collection can happen concurrently. One such what they are called process will not damage or interfere with other processes. That is invaluable.
Erlang's concurrency just like (Go's and Rust's I think) is also a mix of both CPU and IO. So behind the scenes Erlang spawns an operating system thread for each CPU core and then it dynamically scales your concurrency units over them. You need to run better, just add more cores.
Another (and this should be the main differentiation) is fault tolerance. This was and is the raison-d-etre for Erlang. Nothing practical out there matches it. Processes can and will crash and Erlang has standard ways to supervise and restart. Even crazier it provides built in facilities to reload the code while the system is running. That is of course possible in other frameworks and languages but in Erlang is baked in and battle tested over many years.
That sort of makes Erlang a unique tool. It doesn't come without trade-offs. It doesn't for example has terribly fast sequential speed. So if your task is to multiply matrices for example, or computer lots of numbers. Erlang won't be the fastest in that regard. It is also a functional language. It is beautiful I think, especially if you like pattern matching, but some people don't like that.
But if you don't like the syntax, there is way out, the same Erlang virtual machine called BEAM can run other languages. For example a nice new one is Elixir http://elixir-lang.org/ check it out, it is rather similar to Ruby in syntax but includes all the concurrency features from Erlang.
As for resources I would recommend the wonderful and funny online book called:
Erlang has a very nice concurrency approach, particularly if you are into distributed and fault tolerant systems.
But it's ridiculous to say that "only Erlang can do concurrency". Many other languages do concurrency very well in slightly different ways (Clojure, Scala and Go, for example).
[0]: http://matt.aimonetti.net/posts/2013/08/27/what-technology-s...