Elixir: a relatively thin layer around Erlang that you eventually have to learn anyway.

Elixir is sort of a gateway drug to Erlang, sooner or later you want the real thing.

While I agree with the sentiment, there are two superpowers in the mix for me (pun intended):

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

I maintain erlang libraries. I contributed to OTP. I am from Elixir.

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.

I think what you're seeing here is a difference in age and general approach to programming. I learned how to program in the 70's and early 80's. Back then anything that didn't require punch cards and line editors was considered an amazing luxury. I never really grokked IDE's (though: TurboC and TurboC++ got pretty close on Windows) and I tend to remember the bits of a language and eco-system that I need.

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.

If there are no bad tools, why use Erlang at all instead of for example, Java, C, C++ or Python which all have a larger ecosystem and user base?

Because tool quality is only one dimension to a choice. There are no bad tools: but there are tools that are more suitable to a particular purpose. For instance because of interop, existing infrastructure, team experience, access to specialists, natural fit between tool and problem, availability of existing libraries and so on.

So TL;DR: "Elixir is a gateway drug to Erlang, unless you were born after 1979" ;)

The Elixir programmers that I know describe it as 'biting the bullet', going from their familiar environment into something that is pretty alien to them. Instead of all the luxury you are used to suddenly you have to get into the mindset of programmers that didn't have access to all of these fancy tools (and sometimes very useful tools). For example, debuggers are to me a luxury, I am used to reason about what my code does before writing it. If your first reflex upon reaching an issue with your code is to reach for a debugger to see what it does instead of what you meant then you will probably never really train that reasoning ability. This also tends to be a dividing line between 'gluing APIs together to get something that works' versus building something from the foundational pieces offered by the language and then integrating that into a larger whole.

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 was mainly making a joke :P

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.

Add at least twenty years. In fact, I don’t think many good programmers in their 70s and 80s would agree with the sentiments either. The creators of Erlang also seem to think that Elixir adds significantly, according to public statements and interviews.

So... this is so funny because it feels like you totally missed my point.

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.

I'm not addressing those things because we are in agreement there.

As a third person reading the conversation, your original post came across as dismissive in the sense that you referred to Elixir as merely a "gateway drug" and Erlang as "the real thing", an opinion that you provided zero support for. When someone pointed out some of Erlang's significant shortcomings and pain points relative to its modern counterpart, your reply came across as somewhat condescending, in a "oh yeah? well, back in my day..." sort of way, which is how a lot of old people talk down to younger people.

It was a response to the top level comment which did the same thing in reverse.

Anyway, I'm kind of done with the personal attacks so have a nice day.

No need to play the victim, because I didn't attack you personally, merely pointed out why your tone was off-putting. /shrug

I'm a bit younger than you but not much. I looked at Erlang when I learned Elixir because it's handy to be able to read the source code of some modules or understand some examples. There is usually a 1:1 transposition between the two languages. That is, they are the same language with different syntax and a very simple way to translate between them.

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'm quite junior in my Elixir experience at this point.

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.

I've been using Erlang for something like 20 years, and Elixir has some genuine improvements over it, like using "binaries" for strings instead of the linked list/array things.

Yes, strings are a real pain point. And I absolutely believe that if Erlang were to be created from scratch today it would be much closer to Elixir than to the Erlang that is there with all of the historical baggage. But what surprises me is how well it is geared to the problems of the modern web, almost no other platform seems to be so tailor made for web scale event and request processing.

Out of curiosity, what have you built that really took advantage of what BEAM does well?

A message switch.

We'd been using erlang and it was perfectly fine. Then we needed a REST API and I looked at how much work it would need to make it nice and chose Phoenix. For some reasons I still wrote a lib that I'm calling in erlang and because of different string handling it's a bit of a pain.

So for me at least, both have their strength but I wouldn't say you need Erlang, Elixir can work fine on its own.

Elixir brings so much to the BEAM ecosystem with the improved UX from the tooling and libraries. If you want a better language on the BEAM go with LFE in my opinion.

I'm very curious, what's the LFE experience like?

Are you in the REPL all day? Any major interop issues?

I've been writing elixir for 8 years. I've never once wanted to write erlang, nor have I ever written erlang programs.

Same. I’ve had to call a handful of Erlang functions from Elixir over the years but never had to dive deeper than that.