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.
michalmuskala
gregvaughn
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
dimitarvp
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. 
1
peerreynders
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
WildYorkies
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
peerreynders
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
dimitarvp
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.
4
tmbb
Is Elixir faster than Javascript? I’d love to see benchmarks showing that (I’ve always assumed that Javascript would be the fastest dynamic language around due to all the effort done in optimizing its VMs
0