Where is Elixir and the Actor Model heading?

Chat / Discussions
1

It seems that the more I read, the more I find Elixir users speaking about all the ways that Elixir is not good for x, y, and z use cases.

Usually these x, y, and z use cases are not good because “Elixir is not fast enough for raw computation” or something of that sort.

In my mind, Elixir seems like more of an investment. Either:

1. The Actor model is the wave of the future in terms of program design and structure, and investing in Elixir would be a very smart move if even to wrap your head around the actor concepts
2. The Actor model is the wave of the present and is merely the best way to structure distributed apps that we currently have

After all, I’ve heard from people that Actors are not necessarily the best in terms of code clarity OR efficiency. CSP or STM could be better in this area even.

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

The question I’m getting at is are Elixir users/contributors dedicated to the vision of #1 or do they see Elixir as more of #2. I assume that #2 is more likely based upon the way people in this community generally talk.

For example:

  • “Elixir is not good for GUI programming, use something else”. It seems to me that Elixir and the messaging passing system would be ideal for GUI programming. Why just write this off as something not worth pursuing?
  • “Elixir is not good at number crunching, use something else”. Okay, so why not teach/show people how to use the FFI to call out to number crunching C libraries instead? Why abandon Elixir all together?

You get the picture.

tl;dr - Do you think people are drinking the “Polyglot Programmer” kool-aid a little bit too much rather than being excited about Elixir’s future?

7 Likes
2

Message passing is terribly inefficient for graphics calculations. You can bind Elixir to something else, but implementing the GUI in Elixir sounds ill advised.

No one is saying you have to abandon Elixir. But you have to write your “fast” C library anyway. Combining the result of NIFs with calculations done by Elixir is probably not very smart. You should handle all the math inside the NIF and only return tbe final result, to minimize overhead.

2 Likes
3

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.

16 Likes
4

And from what I gather, it will never be, right?

1 Like
5

Generally Elixir programmers are fully aware of its strengths, and how they outnumber its weaknesses, hence are not insecure about it :slight_smile: so are happy to be open and frank about where other languages may be ‘stronger’ (whether, as Michał mentions above, because we lack tools or optimisations or whatever else). However I agree that we need to be mindful of how that may come across, especially to newbies …perhaps by highlighting that it is rarely a problem for most apps.

For instance, number crunching is often referred to - but in what context? If image manipulation, then we can just use ImageMagick (or some other library written in something like C) and which is something we commonly do in all sorts of languages (like Ruby, PHP, etc) with wrappers or tools such as Mogrify or Arc. If you need even more performance than ImageMagick, you can use VIPS, which also has an Elixir wrapper.

The other common one is Machine Learning, but now we have Tensorflowex :003:

With regards to native UIs, we now have Scenic :003:

13 Likes
6

Ideal for high-level UIs. Looking forward to Scenic.

5 Likes
7

For context, let’s use the example of the newbie that is interested in Elixir and Golang.

Golang person: Go is good at concurrency and good at all the other things Elixir is bad at.
Elixir person: Elixir is better at distributing to multiple machines/using more cores.
Golang person: That is not needed because Go is more efficient.
Elixir person: Perhaps, but think about the future!

Perhaps the Elixir person may indeed recommend that the newbie uses Golang for a specific project. But when you are competing for mindshare, and when Golang inevitably creates an Actor library of their own, that newbie may never give Elixir a second thought.

So in my newbie mind, it comes back to the question about where we’re heading or where efforts are being placed in Elixir in terms of improvements.

8

Its worth quote the work of @boydm: 3) ElixirConf 2017 - Elixir Native UI - Boyd Multerer

2 Likes
9

I would not be worried about that anytime soon. The Golang folk can’t even agree on making a standard library sorting for 32-bit integers to be built-in and require you to pass a lambda function for that to actually work. Sorry, only 64-bit integers are supported by default!

Just a random example but the point is that the Golang authors and general community look down on the too much batteries included approach. I only wrote like 15 Golang microservices 2 years ago and the consensus almost everywhere to this day is: “why do you need a library, this is very easy to build on your own” (even if that incurs a 2-4 weeks cost). Granted things have improved a bit since then but when you talk to actual people, the mindset seems to be the same.

To create a BEAM-like environment is a huge task and it would go far beyond just a library – it is likely for that to even be a different compile target, say, x86_64_actors or something (vs x86_64_smp for regular multithreading). And it would most likely mean adding a runtime that your Golang executable must carry with it – they are already quite big so not sure if the core team would support increasing that even further.

The BEAM VM is not in danger of having a good competition for a while still, be sure of it.

5 Likes
10

Then we can just quote Joe Armstrong :003:

9 Likes
11

I would have agreed if these technologies actually had such a well-written runtime like the BEAM (which AFAIK they don’t). We are not talking only about conceptual purity or clarity here; we have to take into account what do we have to work with. I am not ideally informed but last I checked ~2 years ago, CSP and STM were very fragmented areas and there is not a lot of consensus on which library / framework there is the accepted standard tool.

BEAM is a de-facto standard for actor concurrency model.

From what I’ve seen on this forum and when talking to people outside, many people come to Elixir attracted to the benefits of the BEAM, and these are not going away. So I would say they are pretty committed, me included. However all of us are practical folk and we all come from different languages. Inevitably, if somebody is to outdo the BEAM VM, people would move on to there. If we were only here on hobbyist grounds I don’t think most of us would come to Elixir at all (having in mind how many programmers dislike the Ruby-ish syntax) and would probably still dabble in FORTRAN and occasionally write stuff for a living with Haskell or Common Lisp.

So yes – we are committed. And many of us bet money and personal livelihood on Elixir as well.

You might be conflating “Elixir users are not marketing themselves well enough” with “Elixir users are ready to jump ship whenever”. Programmers are not here to do marketing. There are people who are quite good in the area of composing and presenting case studies. Most of us are here to help people, get help, and get our paid work done.

No.

Elixir users are simply realists and very aware that there is no one language to rule them all. There is no “best” language. We know where Elixir and the BEAM VM shine and where it does not.

As a final point, listen to @michalmuskala – the areas where Elixir is lacking are either ripe for disruption (GUI libraries) or never going to change (the BEAM not being suited for raw computing power).

2 Likes
12

Oh, I’m definitely not saying it’s never going to change. The obvious solution for numeric performance is a JIT. There are also some other changes in the VM that are possible. For many of them there are also people how know what needs to be done - it’s more the case of lacking resources to actually do it.

6 Likes
13

For other languages Actor Model’s, the Java/.Net whatever it was called was decent, though Rust’s Actix is pretty fantastic (with all of Rust’s tasty guarantees!).

And Rust makes a great NIF. :wink:

8 Likes
14

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.

16 Likes
15

I stand corrected, sorry.

It’s just that the BEAM technically being an interpreter (of byte code and not text but still an interpreter?) I don’t feel it will ever have an edge against C, C++, Rust, Go, OCaml in raw computing muscle. I coded 8 years in Java and I have witnessed what wonders a well-written JIT can achieve… just not sure it will close the gap enough.

I will be happy to be proven wrong in the future. :slight_smile:

1 Like
16

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

17 Likes
17

I can think of many “general purpose” languages that do most things reasonably well. Golang, Rust, Python, etc.

There is a competing idea, though, that you hint at. The “learn a DSL” system. Elixir could be seen as a DSL for distributed systems. And you could use 10 other DSLs for different things. Markup, Styling, etc.

I am intrigued by the vision. I’ve tinkered with Racket on-and-off for many years for that reason.

But really, I think people are looking for that performant, future-proof, general language so that they can quite simply get the most “bang for their buck”.

Why do people want to learn programming? I think generally because they want to do a lot of cool things with computers. Well, I can do more cool things with x than I can with y. y is better at some things than x, but not by a ton.

It’s like buying a swiss army knife vs a single blade. The single blade might be amazing quality, but it’s just more handy to carry the swiss army knife around in your pocket.

It took me a while to get to that metaphor ^ haha

Yep, I understand that. I just say Actors because it is what made Elixir really click for me to begin with. I think it’s natural for humans to think primarily about the endpoints than about the letters. We want to understand the zoomed-out view, I suppose.

1 Like
18

There is your swiss army knife right there. But people who’ve learned one of those “other” programming languages first, think it “looks funny”- so they dismiss it.
(Some racket links).

3 Likes
19

16 posts were merged into an existing topic: Off-topic (Go related) posts from the Elixir Actor model thread

20

That’s exactly what Elixir is, because among other things (concurrency, immutability, fault tolerance) it’s also faster than most (all?) popular scripting languages. Sure Elixir is slower than Golang and Rust… but it can be anywhere from 5x to 500x faster than Ruby, Javascript, PHP or Python (I mean clean Python, not the 100 metric tons of native wrappers like numpy!) – and that makes it almost a drop-in replacement for them… and for all other native languages if you don’t care about every last cent per watt.

Elixir and a few LISP dialects can all be the swiss-army knife.

Elixir indeed gives you the most bang for your buck. Not all. I think we actually agree with each other but use different terms. :slight_smile:

4 Likes