What boggles my mind is that people are still looking for the “perfect programming language” that will do everything well when since (shortly after) the dawn of the world-wide-web you’ve needed a collection of fundamental technologies (HTML, CSS, JavaScript) to even put together a reasonably interactive web page (not to even mention the supporting server-side technologies). So I hardly think that the “Polyglot Programmer” is in the realm of “Jonestown kool-aid”.

Programming languages are technologies typically optimized for a specific purpose - jack-of-all-trades technologies tend to not do anything particularly well, they are just “good enough” for some people. So if you are working with anything that has a reasonably wide scope you are usually committed to working with multiple technologies and that can mean multiple (specialized) programming languages.

Now, I know that someone will say “Erlang isn’t technically an implementation of actors”. That’s fine, but it’s close enough.

That doesn’t change that you yourself may be too fixated on the Actor model (the same way an OO enthusiast may focus on objects, totally overlooking the “messages”).

The BEAM doesn’t care about the Actor model - it’s about lightweight processes and how the BEAM schedulers manage them. For me this talk expresses the spirit of the BEAM most clearly:

Lambda Days 2015 - Torben Hoffmann - Thinking like an Erlanger

The BEAM is more than a virtual machine - it’s actually more like a mini-OS - one that is smarter about how to get the most (concurrency, rather than raw power) out of the host hardware than the actual OS it is operating on.

Complaining about Elixir, Erlang or any other BEAM langauge not being good enough for all applications is almost like complaining that bash, bourne shell, zsh, etc. aren’t good enough for all applications. The concurrency support means that you can choreograph or orchestrate concurrent activities fairly easily while at the same time being able to “outsource” certain work to other tools that may be more suited for a particular task.

Now some developers don’t want to leave the “comfort and familiarity” of their preferred programming language/environment - but that is a separate issue (and an unreasonable expectation in our increasingly “connected” world).

So competing implementations of the Actor model are largely irrelevant because the real gold is with the BEAM’s schedulers (and to a certain degree “distribution” but more from a local fault tolerance perspective rather than “heterogenous” and “world-wide” distribution).

Elixir could be awesome for GUI programming - we just lack proper tools.

Elixir could be awesome at number crunching - it’s just our VM is not optimised for this.

This are not inherent limitations of Elixir, but rather the result of the current state of the ecosystem.

I’m going to take this off in a slightly different direction. You should not be focusing on the Actor model at all. What initially drove Erlang’s design was fault tolerance. It was built in industry, not academia. Ericsson needed software that kept running in the face of errors. They only accidentally re-invented the Actor model because of that focus on fault tolerance and supervision.

The way I’d phrase an answer to your question, is that the Actor model is the best way we know how to build fault tolerant systems today, but since fault tolerance is the primary driving design choice among the BEAM community, if a better way is discovered, I would expect them to embrace it.