Comment by rubiquity | Hacker News Reader

Comment by rubiquity | Hacker News Reader

Parent Full thread

I've had the most success with describing concurrency and parallelism as follows:

The term "Parallelism" these days is synonymous with "CPU Parallelism." Parallelism has existed for a long time. For example, network cards have been able to do I/O parallelism for seemingly forever. Could you imagine if a computer could only have a single network request running at a time? Therefore, what parallelism (read: CPU Parallelism) means is CPU execution happening at literally the same time. Emphasis on literally.

Concurrency is how we make sense of and communicate the above mess. In the days of single cores, we mostly cared about concurrency as a way to communicate I/O parallelism in a manageable way. Now we use concurrency to express both forms of parallelism in our programs. Good implementations of concurrency (Erlang) make all of this transparent to the user. Bad implementations of concurrency (Node.js) have the user doing all of the work (callbacks).

I am not well versed in Erlang, but have dabbled in some Node. What does Erlang do that makes it better than Node? As far as concurrency is concerned.

Pretty much everything, honestly. Erlang was built from the start to accommodate massive concurrency and robustness requirements, in particular for telecom switches, but largely applicable to anything.

Node's a single-threaded reactor pattern event loop, whereas Erlang/OTP is an SMP-enabled virtual machine with a preemptive scheduler that manages lightweight actors called processes, all isolated from each other with their own stack and heap, that can be cheaply spawned and communicate only via message passing. On top of that, Erlang offers location transparency for processes and easy node distribution out of the box. OTP then provides a framework for fault tolerance and reusable components by supplying generic behaviors (server, FSM, etc.), supervisors for monitoring and restarting processes when they crash, endpoints for hot code reloading, and more.

You should try it one day. There's really nothing else like it, even if its underlying concepts aren't necessarily novel - but they're well combined and largely obscure in mainstream practice. A lot of platforms have tried to implement their own equivalent actor model approaches (Celluloid for Python, Akka for Scala...), but none reach the same level.

> all isolated from each other with their own stack and heap,

That is really a unique property of the BEAM VM. Most languages built on it Erlang, Elixir, LFE, Joxa, etc can take advantage of that.

Often when telling someone technical about how you can have processes that behave like OS processes -- fully isolated heap, and if one crashes it doesn't affect the others, and which are also very lightweight -- only a few KB of memory overhead, they think there is some trick or misunderstanding. Like "sure but they are just green threads" or "they can't be just a few KB of memory, processes have to be bigger than that".

Isn't there a saying something to the effect of "an advanced enough technology looks to many as indistiguishable from magic".

Thanks for the overview! I have seen a lot of hype around Elixir lately, do you happen to know if it contains all of the benefits of Erlang? Coming from a Ruby background, Elixir looks very nice to work with syntax-wise compared to Erlang.

You have all of the benefits of Erlang the language, Erlang the VM and Erlang libraries. Elixir adds hygienic macros, an awesome package manager (hex), task/test runner and build tool (mix). Elixir also has a Ruby-ish syntax, but I leave it up to the reader to make their own opinions of Elixir syntax vs Erlang syntax as that is not a war I'm interested in.

Give Akka some time :).

Erlang has schedulers (one per CPU) that schedules when code gets run. If an Erlang process (Erlang's unit of computation/concurrency) is tied up doing IO, the scheduler simply jumps to another Erlang process. In Node.js you write out callbacks/promises/soup du jour that get run after some specified thing completes. In Erlang your code looks completely sequential.

And on Node.js, whatever thing you run probably gets put into a bog-standard thread pool. So all that's really happening is that your IO requests are getting sent to a limited number of long-running threads. Run enough operations at the same time and you can tie up the thread pool, which most people don't even know exists. In some ways, it's the worst of both worlds: it has the limitations of a thread pool with the API complexity of a callback system.

Isn't Erlang superiority to Node.js grounded in the underlying VM as well?

Couldn't that be said for nearly every programming language that doesn't share an underlying VM? I'm not sure what you're getting at. Do you mind expanding on that?

Reply on news.ycombinator.com