Where is Elixir and the Actor Model heading?

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.

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.

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

Generally Elixir programmers are fully aware of its strengths, and how they outnumber its weaknesses, hence are not insecure about it 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

With regards to native UIs, we now have Scenic

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

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.

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

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.

Then we can just quote Joe Armstrong

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