Note: Erlang is not just a language but one part of a whole system collectively called The Erlang System. Robert Virding was one of the original three along with Joe Armstrong and Mike Williams who designed it and here presents the complete overview of it in the clearest and simplest manner possible.
After watching the above which gives one an idea of the Erlang System's capabilities, watch this presentation by Bryan Hunter where the design and architecture of a complete distributed and fault-tolerant Erlang/Elixir system is shown; You get to really see the mind-blowing power of the Erlang System in this - https://www.youtube.com/watch?v=pQ0CvjAJXz4
Since Elixir runs on the Erlang VM and is more "modern" with modern tooling/resources; should I be using Elixir for new projects or Erlang? (I know neither, but I have a good functional background with Haskell).
Also are there cases where one is well suited than the other?
Think of the relationship between Erlang->Elixir as that between C->C++. The latter is effectively built on the abstract machine model defined by the former. So whether you prefer Elixir or not you have to know Erlang. This becomes even more true when you have to go outside the Elixir/any other BEAM based language ecosystem but still need the BEAM facilities.
The Erlang System is actually an "Application Operating System (AOS)" (Joe Armstrong's definition) and the "Erlang language" is its "native system language". An analogy is writing Python code running on Linux but making a kernel system call through the C language interface. Here Python is your Elixir, Linux is the Erlang AOS(ERTS+BEAM) and the C language interface is the Erlang language interface.
PS: I hope you have watched the two videos i have linked to in this thread, they are well worth your time and answer all your questions.
> Think of the relationship between Erlang->Elixir as that between C->C++.
This is not right. It's more like Java -> Kotlin
> So whether you prefer Elixir or not you have to know Erlang.
Not really. You can get quite far in Elixir without knowing any Erlang.
Eventually you probably should learn to read Erlang docs (but not necessarily code) and maybe you might need to be able to read Erlang code, but this is truly rare.
As usual, it depends on the use case. Enterprise vs hobbyist, for example.
I greatly admire the principles, but in practice, the Erlang platform underdelivers in a modern context, because applications are usually not deployed by hot-swapping, but by rollout on Kubernetes. High availability is achieved by load balancing over horizontal scale-out of pods. Distributed systems today use external systems for state, like databases, keyvalue/caching stores, message queues, etc.
Elixir is a convenient language, like Python, with lots of convenience tools.
But for a long list of reasons, I wouldn't use it for anything other than prototyping/hobby projects.
> I greatly admire the principles, but in practice, the Erlang platform underdelivers in a modern context, because applications are usually not deployed by hot-swapping, but by rollout on Kubernetes. High availability is achieved by load balancing over horizontal scale-out of pods. Distributed systems today use external systems for state, like databases, keyvalue/caching stores, message queues, etc.
I can believe that there are reasons to avoid BEAM in production, but "all the other ecosystems solve the same problems differently" isn't a good reason. One reason to choose the BEAM is because it offers solutions to all of these problems as part of a single coherent ecosystem. Yeah, you'll be confused if you try to take the BEAM and then roll it out on K8S, so maybe just... don't do that?
If you want to compare and contrast BEAM's solutions with the more typical modern suite, that would be more persuasive. Just saying "it's bad because it's different" isn't, because the differences are why people are interested in it.
WhatsApp, famously launched and served millions of users with a small team using Elixir. Seems to me that speaks to the language's production capability, or enterprise capability, if you will. Considering that, can you go more into detail about your assertion here?
> But for a long list of reasons, I wouldn't use it for anything other than prototyping/hobby projects.
Readit News
https://www.youtube.com/watch?v=JvBT4XBdoUE
discussed here: https://news.ycombinator.com/item?id=20942767
https://www.youtube.com/watch?v=rRbY3TMUcgQ
Also are there cases where one is well suited than the other?
The Erlang System is actually an "Application Operating System (AOS)" (Joe Armstrong's definition) and the "Erlang language" is its "native system language". An analogy is writing Python code running on Linux but making a kernel system call through the C language interface. Here Python is your Elixir, Linux is the Erlang AOS(ERTS+BEAM) and the C language interface is the Erlang language interface.
PS: I hope you have watched the two videos i have linked to in this thread, they are well worth your time and answer all your questions.
This is not right. It's more like Java -> Kotlin
> So whether you prefer Elixir or not you have to know Erlang.
Not really. You can get quite far in Elixir without knowing any Erlang.
Eventually you probably should learn to read Erlang docs (but not necessarily code) and maybe you might need to be able to read Erlang code, but this is truly rare.
I greatly admire the principles, but in practice, the Erlang platform underdelivers in a modern context, because applications are usually not deployed by hot-swapping, but by rollout on Kubernetes. High availability is achieved by load balancing over horizontal scale-out of pods. Distributed systems today use external systems for state, like databases, keyvalue/caching stores, message queues, etc.
Elixir is a convenient language, like Python, with lots of convenience tools.
But for a long list of reasons, I wouldn't use it for anything other than prototyping/hobby projects.
I can believe that there are reasons to avoid BEAM in production, but "all the other ecosystems solve the same problems differently" isn't a good reason. One reason to choose the BEAM is because it offers solutions to all of these problems as part of a single coherent ecosystem. Yeah, you'll be confused if you try to take the BEAM and then roll it out on K8S, so maybe just... don't do that?
If you want to compare and contrast BEAM's solutions with the more typical modern suite, that would be more persuasive. Just saying "it's bad because it's different" isn't, because the differences are why people are interested in it.
> But for a long list of reasons, I wouldn't use it for anything other than prototyping/hobby projects.