Hacker News Reader

Comment by dragosmocrii | Hacker News Reader

Elixir/Erlang is concurrent, not parallel though.

Not to pile on with the rebuttals, but Elixir/Erlang are actually truly parallel. There wouldn't be much point to all the interest into it unless they were. You should go to the phoenix framework website for statistics on how it handles many connections and processes.

Of course, true parallelism only comes with multicore CPUs anyways, and this is what the Erlang VM ("BEAM") is geared to. The processes are not threads in the C++ sense and there is no shared memory, but there are separate BEAMs for each CPU core and the processes are scheduled to them. Message passing in the Actor style takes the place of shared memory.

Erlang is as parallel as it gets. Async message passing actor model. The runtime will distributed the processes (actors) over the available CPUs.

See: https://www.culttt.com/2016/07/27/understanding-concurrency-...

To best of my knowledge, Erlang was not built for parallelism, but concurrency. When the language was created, multicore CPU where not yet available. The following article can explain better the point.

http://jlouisramblings.blogspot.com/2011/07/erlangs-parallel...

This is pretty old. They have per-core actors and GC for a long time now.

It's true that when Erlang was first made, machines were single-core, so parallel execution was not possible on one machine. However, the "no shared memory" process model made transitioning to true parallelism much simpler. The ability to run one scheduler per core was added around 2005 I think. See https://hamidreza-s.github.io/erlang/scheduling/real-time/pr...

Also:

> Erlang achieves concurrency by interleaving the execution of processes on the Erlang virtual machine, the BEAM. On a multi-core processor the BEAM can also achieve parallelism by running one scheduler per core and executing one Erlang process per scheduler. The designer of an Erlang system can achieve further parallelism by distributing the system on several computers. > https://happi.github.io/theBeamBook/

My understanding is that the BEAM will also do "work stealing" among schedulers to take better advantage of the available CPUs.

The OTP is both.

Reply on news.ycombinator.com