[59nadir]

Learning how the BEAM works and the architectural decisions that make sense for running your system on it is the realistic growth path for any serious BEAM developer. This has nothing to do with any of the languages on the BEAM, but with what makes sense on the VM.

Your assertion that abstraction is somehow not needed in "large complex systems" (this being completely undefinable, by the way) seems silly and I can refute it with about as many objective reasons as I suspect you have for making that comment. Our current code base would be significantly shorter if we used Elixir (on the order of 50% less code, conservatively approximated) and is an absolute bitch to spelunk in specifically because it's just Erlang.

There is no reason to create a new project in Erlang (instead of Elixir/LFE) outside of reasons like handing it off to clients or the like and the focus should never be on learning Erlang, but on the BEAM. Any knowledge gained through that is trivially used in one of the more productive languages on the BEAM.

[ams6110]

50% less code? Can you provide some more specifics? That seems like a bold claim.

[59nadir]

We use REST for both internal and external calls to services (a mistake, in my opinion) and while Erlang actually has frameworks for this, none of them are good and cowboy_rest requires lots of boilerplate. Doing it with Phoenix would cut out lots of entire modules and replace them with functions without paying any real cost.

I like Erlang, but there's no upside to using it instead of something else that runs on the BEAM, apart from making a basic library that you want to use both from Erlang and Elixir (I don't know what the situation for compiling Elixir with rebar3 is).

Effectively, Erlang is to Elixir what Java is to Kotlin, except there are even less performance differences and no compatibility issues. It makes perfect sense to learn Erlang syntax and learning the semantics of it will mean you've learned BEAM semantics, but you might as well do that in Elixir and actually have a better road to it.

Edit: I'd like to add that I find a general lack of tools for dealing with boilerplate in Erlang. It also has a generally outdated functional programming skew in that it doesn't at all facilitate pipelining and this makes it less attractive to make nice abstractions like Plug(0), for example. This is exacerbated by the fact that collections aren't abstracted over, so whenever you end up dealing with them there's lots of sighing and docs checking to see what the argument order was the week they designed that particular module and that particular function in that particular collection module.

0 - https://github.com/elixir-plug/plug