Just dipping my toe into Erlang and Elixir.
Seems there is almost 1-1 mapping between the two - with Elixir being slightly more concise but ultimately producing the same beam code.
Elixir seems to have more momentum behind it at this point - more new activity on github, more new books published - and some nice frameworks like Nx (neural nets) and Phoenix.
Any reason - other than habit - to prefer Erlang over Elixir?
Welcome @reymono!
I actually find Erlang can be more concise than Elixir in several occasions. Erlang is also a simpler language. At the end of the day though, you are right they are similar and because both run on the Erlang VM, they interoperate just fine. So there should be no problem to start with Erlang and add Elixir or vice-versa.
If you want to be practical, you can look at libraries and frameworks (do you have a need in particular that could push you towards one language or another?). And, if you have a team, you could decide together.
Erlang is the ācoreā language of the BEAM but, ultimately, itās the BEAM thatās most critical in delivering the disruptive capabilities of things like OTP. Erlang is clearly a bit closer to that model but also more esoteric. It was made to run inside telephone switches by engineers whose priorities are made clear as you get deeper into it. Text handling and tooling were not major priorities (although both have improved vastly over the years) but resilience, concurrency, low overhead independent actors, conciseness and logic were the focus. Elixir comes from the Ruby/Rails community which was primarily doing web services on top of databases. Being willing to inject some āmagicā to hide a lot of behind the scenes complexities and a focus on strong tooling to get you to your core use cases quickly were prioritized as well as syntax that felt more imperative and accessible to ānormalā devs.
The Elixir community has come in and built on top of OTP bringing along this focus on tooling and āease of useā which has forced/helped the Erlang community to appreciate some of the benefits of these things. Just a year or so ago I would say you canāt be a great Elixir dev without also knowing Erlang. But Elixir has now wrapped and extended so much of the BEAM/OTP capabilities in ānativeā Elixir that I would now say you canāt be a great Elixir dev without knowing OTP well. Either way - being a capable Erlang dev is going to help you greatly in being a capable Elixir dev. Fortunately the two interoperate quite easily.
The biggest general differences I see between Elixir & Erlang teams/devs is Elixir teams do tend to work on the assumption of a 3-tiered architecture where most requests ultimately hit a database. Erlang teams tend to appreciate the āorchestrate a bunch of actorsā and make databases something that might be needed to cache data persistently but prefer to have distributed copies of live actors so databases arenāt really needed and then use far less complex databases (never an enterprise RDBMS model with 50+ tables) for highly domain specific uses. So figure out which scenario you find is upon you and arm yourself accordingly.
FWIW - my team defaults to Erlang especially for business logic and backend stuff. We do a lot of highly distributed high capacity work where hitting a database for each tx would simply destroy our performance. But when we build apps that have a lot of asynchronous web front ends we have grown to love Phoenix/Liveview (which is Elixir stuff) which lets us avoid having to spend a lot of time doing front end Typescript coding yet still give the users a remarkably responsive and capable user experience. Our Liveview apps generally donāt talk to Ecto databases, however, but rather Erlang actor processes from our backend efforts.
Both are great technologies. Elixir clearly is more accessible to newer devs with less formal engineering training (and maybe even to those!). Erlang is succinct and, once learned, amazingly powerful when you think in terms of capabilities per line of code to be maintained. Itās amazing what you can build with only the Erlang OTP distro and no other dependencies in a very short period of time. I think, eventually, when you hit the sweet spot on one of them pertaining to your actual needs, eventually youāll discover the value of the other as new challenges present themselves. And thereās other languages existing for BEAM and that continue to be developed that may also play a valuable part.
Trust the BEAM and all who abide by it.
ā Ben Scherrey
The differences between Erlang and Elixir are by now more cultural than anything else. I personally dislike Elixir syntax but there are plenty
of people who disagree. They are not the only alternatives. Thereās
LFE (Lisp-Flavored Erlang), which I appreciate. Thereās Gleam (find out
more at gleam.run) which is worth considering if you like static typing
by default. There are 34 languages for the BEAM listed at
https://github.com/llaisdy/beam_languages but many of them are no longer
actively maintained.
Erlang, Elixir, LFE, and Gleam can all call each other, so you should
probably consider personal taste and cultural āstyleā.
Erlang vs + Elixir
In my experience the further away i went from Phoenix app and more towards distributed system the less resources i found for Elixir and more for Erlang. Sure they were 20 years old but donāt let that put you off 
I think when it comes to distributed systems Erlang still has some aces up its sleeve.
Common Test for example. (I do miss the nice assertion diffs from ExUnit)
Many thanks.
Plan to dive deeper into Erlang and OTP later - have read Joe Armstrongās Erlang document and am currently reading Elixir in Action.
Elixirās mix tool reminds me of Rustās cargo - which is good.
Also feels like some of Rustās pattern matching - e.g. match statement - is related.
Sometimes think there are more languages in the world than there should be - Erlang is different though; few languages put concurrency first. Will have a look at Armstrongās PhD thesis also - surprised it is only from 2003.
Personal taste (probably formed from habit :). I prefer the Erlang syntax (I think it is actually often more concise) and prefer rebar3. So Iād suggest playing with both and going with what you like the best, and as you say the mapping is almost 1:1 so you can jump between them if find you need to work in the other for some reason.
Seems there is almost 1-1 mapping between the two
Last time I checked, Elixir compiled to Erlang, rather than directly to BEAM bytecode. So the mapping from Elixir to Erlang may or may not be surjective.
I assume most people starting with Elixir today do so because they think itās the latest version of Erlang, in the same way that people mistakenly believe that C++ deprecated C.
Iāve never used Elixir because I was already fluent in Erlang when it arrived and I understood it to be meant to be more approachable so that wasnāt solving a problem I had. Given the increasing number of libraries for Elixir Iāll probably use it one day.
I started my journey with Elixir, and that brought me to Erlang as well.
Learning Erlang made me a better Elixir developer. The deeper I went with Elixir, the more often I found myself reading Erlang documentation, so I had to become familiar with the basic syntax, at least to be able to read the documentation.
Elixir felt more beginner-friendly, but now I think Erlang is actually simpler.
You can call Erlang within Elixir code and vice versa, but the latter is a bit more complicated. Also, you need Erlang installed on your machine to code in Elixir, but you donāt need Elixir to code in Erlang.
Elixir has more third-party libraries available and thatās why I have chosen it over Erlang sometimes(I really like the Phoenix framework for example) but Erlang has a bigger standard library.
In the end both compile to BEAM so I guess theres nothing that one language can do and the other canāt.
It may be more convenient to use one over the other depending on the use case.
I like both languages 
I started with Erlang in 2020. I was able to implement a web server (using cowboy), use Mnesia for data storage and able to encrypt/decrypt client requests using Erlangās public_key functionality. I found Erlang to be powerful, concise and absolutely indispensable when it comes to fault tolerance and stability. It is also an unforgiving language, so it makes you a better programmer. On this journey, I did try Elixir. Iām just not down with that syntax. All those do/def/end, defmodule. Not to mention the ā:ā before an atom. Erlangās elegance and simplicity are hard to beat.