Hacker News Reader

Comment by pdimitar | Hacker News Reader

Professionally and for personal projects I go with Elixir. Having 99% transparent parallelization of any task is irreplaceable in our multi-core CPU era (especially having in mind that CPUs seem to have more and more cores lately -- see AMD). Functional programming improves the way you reason about your tasks as well.

Having a simple language living inside a 30-year old runtime and being able to reach for pretty advanced tools if you need them, is heaven. Not everything is ideal though; there are still holes to be filled in the ecosystem.

If you do something more serious and need compiler help as much as possible, I'd say go for OCaml. Its multi-core parallelism story is still not good but there are ways around that. I hear from some people Idris is good as well.

View on HN

If your app is going to do anything real-time with lots of messaging or reactive / live behavior, then Elixir is going to hit it out of the park. There's a reason Discord and Whatsapp are using the BEAM.

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...

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.

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

The OTP is both.

Reply on news.ycombinator.com