Erlang is particularly good at distributed concurrency. Erlang loses much of its value when deployed only on a single machine. Also, Erlang's single-minded focus on keeping the application going may be a little overkill for compute.

There are at least two reasons why Erlang for single-machine concurrency is bad:

1: Erlang is slow. It just is. They're working on making it faster, but Erlang has a inherent overhead coming from its focus on responsiveness and uptime. Let-it-crash, actor monitoring and one-GC-per-actor isn't free.

2: Erlang's concurrency model is based on the actor model, which assumes infinite message queue capacity. In case of insufficient memory, messages are simply discarded. While this is something you have to deal with anyway in multi-machine systems (think network buffers) it's an unnecessary worry in single-machine ones.

Now, Erlang is designed to call into native binaries for all of its single-thread high-performance needs, so assuming you only use Erlang to handle inter-thread communication on a grid/supercomputer and that communication isn't a super-frequent event, then I guess Erlang+C/FORTRAN/Julia makes sense. I guess it's the convenience of having a single language that speaks for a pure Julia solution, more than anything else.

Erlang is very good at concurrency, this talk is about parallelism. For a purely parallel task Julia should be much faster. It has many other advantages like being very good at generic programming and interfacing easily with native shared libraries.

A big thing Julia has going for it is that it plays nicely with Fortran. Lots of legacy numerical computing code has already been written in Fortran, so it's a big draw for some companies.