The heart of Elixir :)
Elixir is sort of a gateway drug to Erlang, sooner or later you want the real thing.
I cannot agree. Erlang is a pita to with. From the lackluster test libraries, the lack of module aliasing, the atrocious UX of parse transform, and so much more.
Erlang bring nearly nothing that Elixir cannot do and the UX of elixir is by far better.
And I am not talking of syntax here.
Erlang was made by and for that generation, with the tools that were there at the time and so it 'speaks to me' in a way that I'm familiar with. Going on the assumption that you've learned to program a little later, by the time that eco systems were more fully featured, IDEs were commonplace and things like test libraries and namespaces were common I can totally understand why something like Erlang would leave you frustrated.
But to me it is a luxury and always will be. So long term, Elixir probably has the future, but that battle hardened foundation that it builds on stems from a different era, where reading the documentation was a prerequisite for doing anything with a system and all systems had their little quirks. Erlang's roots in turn are partially in Prolog, which is another one of those beasts of times long gone, it too is quirky and some of that shows through in Erlang and the way it approaches things.
In my experience it pays off to embrace such things rather than to fight them, then you can spend your time and energy far more productive rather than to let it be in the front of your focus while you're trying to get some work done. In the end it is all tools, and just like in the trades there are no bad tools.
OTP is a fantastic example of this sort of thing: it is arcane, fairly complex but surprisingly well built and the quality of the architecture is something most modern frameworks can only dream of. The only reason it is still around is for the same reason that crocodiles are still around: it is extremely well adapted to the niches where it is present, all the other stuff has died out. You can re-invent all (or usually part) of OTP in any language and there have been many attempts at doing just that. But why would you? It already exists and it is far more battle hardened and time tested than anything new likely will ever be. Ok, you'll have to bite that bullet...
I think many web developers do just fine without ever having to touch Erlang, which is one of the nice things I like about Elixir: it's making a platform that is almost tailor made to web development really accessible to web developers. There is an idea outside the ecosystem that Elixir is "overkill" for simple apps but that's just not true!
For those that find themselves needing to dive into Erlang, I too have seen several people describe it as "Biting the bullet," and I'm a bit in that camp myself. For me it's not Erlang the language that's a problem, it's the documentation. This speaks to what you said about being from another era. I just do not find it enjoyable to read.
You otherwise seem to be saying that modern tooling is bad because it doesn't force you to be as diligent a programmer. I neither agree nor disagree with this but it's a whole other convo.
I did not talk of reading documentation because i am literally one of the person you should come to if you need something in the doc. I learned how to write elixir and erlang by reading their doc.
I also do not use an IDE and am really relucant of them because i don't find them useful.
And I am a big defender of prolog. And i am not denying the strong architecture and infrastructure of erlang. I literally contribute to it.
But what you have not addressed is ... all I mentioned. The broken testing libraries. The inability to do the right thing nicely because the parse transform are a pita. The fact that modules names cannot be aliased, generating painful to navigate file structure and names. Etc etc.
And look. It can be made better. We have worked on documentation and there is more coming. We are getting multiline strings. Rebar3 mostly work. Hex can be used for erlang projects.
But in order to do things better we need to acknowledge the problems. Not just say that the kids don't understand. Especially when the person you say that to is actually understanding it pretty well thank you.
Anyway, I'm kind of done with the personal attacks so have a nice day.
That said, Elixir is nicer to read but I was spoiled by Ruby. Erlang is nicer than most of the stuff of the 80s though.
However I wish the Elixir team had more courage and did without all the boilerplate of those handle casts and calls in servers. They used macros to do all sort of things, so I guess they could use them to bury that complexity into the depths of the language and let us use real function names to call servers. It would start to open a gap between Elixir and Erlang but it would be worth it.
I've found that reading any source code is made orders of magnitude difficult by the use of metaprogramming. Sure, it makes things much easier for people who are just picking up the language, but at the cost of imposing a literal wall in front of them when they try to go in deeper.
Case in point, is metaprogramming in Ruby on Rails. It's just not worth it if used that extensively. I'm very thankful that the Elixir source is super approachable for anyone who wants to read it.
So for me at least, both have their strength but I wouldn't say you need Erlang, Elixir can work fine on its own.
1. Erlang / BEAM itself as the runtim with lots of powerful capabilities (what you probably are talking about) - you need to know this stuff at some point to fully leverage the technology
2. Elixir the language (+ excellent modern tooling) ontop, which really helps to significantly speed up productivity/average code quality - I don't like to over-reductionist approach here, DX is also an important thing to consider instead of the raw foundation
Are you in the REPL all day? Any major interop issues?