Where is Elixir and the Actor Model heading?

Hi all, please note we have posted a dedicated Go vs Elixir thread - if you can, please take part in that for all your Go related discussions :slight_smile:

We’ll leave the Go related posts in this thread for a few more hours, then split them into a new thread and move it to the off-topic section where threads get auto-closed - so if you have any important points relating to this specific discussion feel free to make them before then :smiley:

1 Like

I think the discussion neglects a lot of important BEAM centric points.

We might liken primitive BEAM processes, as spun up by Process.spawn, to actors. It’s hard to do anything meaningful when processes are isolated to the extent that you don’t know about their failure. BEAM processes remedy this with the link and the monitor. OTP builds on top of these primitives to give us the Application, Supervisor, and Generic Server. That’s how we design and structure Elixir projects around concurrency and falt-tolerance. There’s a lot of value there. OTP brought Elixir’s concurrency model to a conclusion a long time ago by building on these primitives [1].

STM doesn’t offer any concurrency (it’s about data). What exactly constitutes STM aside… Erlang/Elixir have ETS so we have those efficiencies. They’ve had it for a very long time. Perhaps before STM had a name.

CSP is interesting but I’m not sure how much it (I presume the channel) helps w/ clarity. There are a couple of points to consider:

  1. OTP is the vehicle we use in practice. It makes for much better code structure than our primitives. The Actor Model and CSP are theoretical. If CSP is just as theoretical as the Actor Model… and we liken BEAM processes to actors… then Go’s concurrency model may only be as useful in practice, or there about, as primitive BEAM processes. Perhaps something analogous to OTP will be built on top of Go’s go-routine and channel [2].

  2. Erlang made a practical choice. They opted away from a channel-like pipe and pipe algebra because it wasn’t as useful for their users as the model that we have today. That might have been their application area, the details, their users, their particular implementation, their times, or the BEAM model might in-fact have a more general practical advantage (or not).

Let’s not conflate the Actor Model w/ the way we build Elixir projects because OTP makes them sufficiently different to warrant a distinction.

[1]: Kubernetes’ and similar projects are quite like OTP but extended to more than one machine.
These projects are for building distributed systems beyond a small number of machines not a language alone.

[2]: I can’t see them using the Actor Model because they’re using CSP.

3 Likes

Wonder what the status is on JIT project :). https://twitter.com/francescoc/status/872737190895288320

^ This! When needing to work on an operator I tried to just use Go but it wasn’t even just Go anymore… and so much has to be generated. Gave up and started working on k8s operator framework for Erlang, much nicer.

3 Likes

Would you please post a link?

Ah yea, the main lib is https://github.com/tsloughter/kuberl which has a watch behaviour https://github.com/tsloughter/kuberl/blob/master/src/kuberl_watch.erl

I haven’t done much with it yet but this is the start of an operator using the watch behavior https://github.com/SpaceTime-IoT/vonnegut_operator

1 Like

I’m new here and I don’t know how people feel about reviving dead threads, so I apologize in advance.

I have gotten to the point of my career where I’ve done a good amount of things… web applications, desktop applications, live video streaming, a decent bit of data science, and most recently distributed systems… I think I have reached a point where, although I still don’t want to do just one thing for the rest of my life. I do want to specialize and become an “expert” in something. I am currently working in Scala and Akka, and I think I would like that something to be distributed systems. That being said, I think different languages/tools offer different pros and cons for different things, BUT it is also definitely true there are some languages/tools that are better suited for certain things than others. For instance, you can compare JavaScript and C++ all day long, but C++ will always be better for computation intensive applications, and JavaScript will probably always be better for building a web application front end. Correct me if I am wrong about anything, and feel free to disagree.

Now to get to my question: I have become interested in Erlang/Elixir in the context of distributed systems/applications. What advantages does it offer over Scala + Akka + Kubernetes (which is, apparently what Tesla is currently using)? I don’t have a specific application in mind for the future and I’m using Scala + Akka at work because it’s what the system I’m working on is written in and I’m still relatively new to it. People around me seem to be extremely interested in Akka streams…

Anyway, thinking ahead, if I were to seriously survey Erlang/Elixir what should I be on the lookout for in terms of picking a tool for a specific problem when it comes to the area of distributed systems and applications? Like if I were to come up with an idea for an open source distributed systems project tomorrow to work on in my spare time, investing in learning a new tool were definitely an option, and I had the freedom to pick whichever technology I wanted, what criteria should I consider when deciding on whether it should be Elixir, Scala + Akka + Kubernetes, or something else?

tl;dr - relating back to the point OP was making, I’ve more easily come across people on the internet describing where Elixir and Erlang do poorly (computation-intensive apps, graphics programming, etc) than where they’re absolutely #1… Where is Elixir the undisputed champ so if I want to design some App, X, I can more easily decide “Another app Y would probably be better written in something else, but X definitely has features that pretty much require that I use Elixir or Erlang to get to a clean solution because even “similar” tools like Scala + Akka would require a lot of hacks/workarounds”?

Mostly Erlang’s OTP and Elixir’s additions on top of it – processes, Tasks, Agents, GenServers, Supervisors, and all that jazz. The reason OTP is much ahead than Akka and others is that they don’t go all the way to fault-tolerance and lagless operation while OTP (and the BEAM VM itself) is designed so the system keeps a predictable lag even under heavy load. Furthermore, order and deliverability of messages to processes is guaranteed.

There’s no other runtime system like BEAM / OTP that can utilise the actor model so well. It simply does not make mistakes, ever. And where you make mistakes, the system allows for self-healing (if you use OTP’s primitives).

Add on top of that this system can almost transparently do parallel processing while 99% of all other languages and frameworks are just making their first steps, and you can see why the people who heavily use Erlang and Elixir are fans. The runtime is simply light years ahead of everything else in these departments (although as already mentioned, it is not the most performant one). Sure everybody else can spawn threads but that’s extremely error-prone. The actors plus the transparent multiplexing on all CPU cores is proven historically to be the much better programming model.


As for drawbacks, you have correctly identified them. I like to think that this community is much more objective than many others because you will not hear people here say “just use Elixir for everything!”. On the contrary, there’s a number of scenarios where it’s not a good fit, as you discovered.

If you need a system that doesn’t make mistakes in its contracts and promises and which can parallelise tasks almost transparently, and is quite adequately fast as a bonus, Erlang/Elixir are your tech. You simply can’t make a mistake using them, and the community periodically adds support for more arcane / corner standards or protocols or data serialisation formats.

If however you need a lot of raw speed, or simply can’t convert your organisation (“we can’t find Elixir devs” seems to be a often-repeated mantra) then just don’t risk it and use either old tech like PHP / Python, or a new and emerging and constantly improving tech like the Rust ecosystem.

Erlang/Elixir are fantastic glue languages that can also do much more in addition to that role. I’d pick them for 80-90% of any random project I might have coming my way. For everything else I’d go for Rust or, if I have no other choice, PHP/Python/Ruby.

2 Likes