[vvpan]

Wanted to add to the usual "why is BEAM not more popular" conversation that there is also Gleam [1], which is an up and coming typed language on top of BEAM. It has the more common C-like syntax and a growing ecosystem of libraries, for example Lustre [2]. Unlike Elixir it has a much tighter syntax without all the macro magic. It also does not wrap around Erlang processes and you have to use those directly. To myself I see it as more of a Go for BEAM, although I am sure people would criticize me for making such generalization.

It sucks that syntax matters but it kind of does. I, for one, am somewhat put off by meta-programming and flexibility of Elixir. The idea of having to learn a syntax per-library I struggle to see the benefits of. I have never programmed Ruby or Lisp so perhaps I have not experienced the joy of what Elixir has to offer...

[1] https://gleam.run/

[2] https://github.com/lustre-labs/lustre

[OutOfHere]

Gleam is a tooling development language, not a concurrency language. It runs away from Erlang's concurrency ecosystem. Also, its documentation, especially wrt concurrency, is sorely lacking. In its current state it would be a mistake it to use it for any distributed work, but perhaps this can change in time.

[kamma4434]

From what I understand, you get all of OTP as it is now – You only use the experimental Gleam packages if you want types. So you should be able to use them right out of the box, with the same level of guarantees (or lack of) that you get in Ex/Erlang. Still, I have not yet found a compelling reason to switch over – or at least try – Gleam.

[vvpan]

Ah, I did not realize that. What is the point then? Why have a language on top of Erlang that "runs away from Erlang's concurrency ecosystem"?

[OutOfHere]

Gleam has some third-party package(s) for concurrency, but I wouldn't consider them mature, and they wouldn't compare to anything like what Elixir has. It is not the primary or even the secondary focus of the Gleam language. I guess there is no point for me.