[pdimitar]

I partially agree, but none have the preemptive green threads of the BEAM VM and its amazing tooling around supervisors and worker hierarchies.

Trust me, if somebody puts that in Go, Rust or OCaml -- I'd ditch Elixir tomorrow.

The BEAM VM is just too good. You can have thousands of smaller tasks running in parallel and nothing lags until you hit the physical limits of the hardware -- which 99% of the apps never do.

[59nadir]

I think this is right on point. The BEAM is finely tuned for a specific problem and it solves it beautifully in a way that is extremely hard to replicate unless you actually are willing to invest in some kind of run time (which instantly makes you ineligible for consideration in a lot of peoples' minds). Every language that has tried, as far as I know, has done so as an afterthought and obviously does not end up replicating the important parts.

Knowing that, it's perhaps more pertinent to talk about what you can actually bring to that VM. Alpaca [0] could potentially be the solution. Interoperation with the rest of the VM languages and static typing on top of that. I have no doubt that most of the community would simply not use it, because they don't care about static typing, but I have zero reservations about saying it would be a better way to write code for the BEAM in the future.

Without something like that, it's unlikely that I will actually put any code that does more than something like routing messages to other services or the like on the BEAM in the future. Beyond a fairly low number of lines I simply don't trust anyone to write code that does exactly what they think it will do and no more in a dynamically typed language.

[0] - https://github.com/alpaca-lang/alpaca

[pdimitar]

> The BEAM is finely tuned for a specific problem and it solves it beautifully...

Not disagreeing with you per se but that was true 10 or 20 years ago. Nowadays the BEAM is very solid general-purpose runtime with the best parallelism on the planet attached.

> Knowing that, it's perhaps more pertinent to talk about what you can actually bring to that VM. Alpaca [0] could potentially be the solution.

Realistically, I'd say that ship has sailed. Elixir has a lot of inertia for that to happen at this point. People focus really hard on improvements over Dialyzer (like Dialyxir + improving warning messages), linting, standard formatting, higher-level code generators and what-have-you.

At this point I'd think an OCaml-to-Elixir transpiler that enforces the compile-time guarantees of OCaml and translates them to Elixir code is the much likelier road to strong static typing on the BEAM. I might be wrong though, it's just a speculation.