As mentioned in a reply to your sibling comment, the lack of static typing is definitely a minus. Not denying it.

Full laziness I found quite overrated while trying to write several very small business services in Haskell. Even in Elixir when you can utilise laziness in limited areas (in the I/O processing stdlibs, but there are almost no data structures for it) it's a proven fact [with benchmarks] that unless your data is at least a list with 500+ elements then laziness introduces both performance penalty and complexity. Not bashing the idea but it's not so universally good as several groups of rather religious programmers seem to make it. Right tool for the right job and all. ;)

Macros is Elixir are quite powerful and very different from stuff like it's done in Ruby. They are basically compile-time code generators, utilised with crushing success in Phoenix (web framework), Absinthe (GraphQL) and Ecto (DB data mapper library). Friendly programmer advice: don't underestimate Elixir macros. Many people stayed with Elixir mostly because of them.

---

> When the JVM finally supports preemptive multi-tasking, Erlang and the BEAM will become completely unnecessary.

1. Maybe, but I was hearing about preemptive multi-tasking on the JVM when I gave up on Java and that was around 2009. Believe me when I tell you, I really want at least 4-5 other runtimes to gain the capabilities of the BEAM. But alas, they still don't. Only Rust 3rd party runtime devs seem to be truly trying to push the envelope. Everybody else is like "yeah, we're gonna get it done by 2050, no worries". Sorry if that comes across as a bit cynical and dismissive, but I do read history.

2. The preemptive multi-tasking of the BEAM is indeed a huge selling point but not the only one. The actor model -- basically green threads with message inboxes -- are historically being proven more and more as a much more successful parallel computing model compared to... pretty much anything else. Really good Golang devs can kinda-sorta-partially emulate that with channels and mutexes/semaphores but it's obviously manual and error-prone. Rust's `actix` devs also agree and if you look at Techempower's benchmarks that try to emulate real web apps, you'll notice that `actix-web` is on top. Kinda funny when you think about how many people here in HN keep saying the actor model is only a good idea on paper and would never perform well in practice.

Additionally, if you keep an eye on the whole ecosystem (as much as that is actually even possible) you'd notice that almost everyone, JS included, is begrudgingly moving to immutable data and lock-less synchronisation. A lot of tech is starting to come to grips with the reality of us humans being flawed and not as bright as we'd like -- me included. I paid my dues with manually crafting mutex and condition variables workflows in C for years, then translating that to Java, then Go, etc. And I can confidently say: it doesn't work sustainably well. You can make a few simple pieces with it but for long-term projects, just go with immutability and lock-less sync.

---

I guess my point is, Erlang/Elixir are still quite strong and don't have much serious competition in their niche (where they are doing well).

Lastly, I agree that the BEAM in general isn't the fastest thing to run code on. Absolutely. In practice however -- and I mean importing a few million lines of CSV/XML a day -- I found that if you invest just a little more effort, Elixir will stay out of your way and your code will be mostly I/O bound. I mean yeah, Elixir isn't as fast as C++ or Rust. But I already used it for several pretty different projects and it has been performing absolutely excellently.

I am looking forward to learn Rust's `actix-web` though. I feel it could be a better fit for some more dramatically more computationally demanding web projects.