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
Agreed - I just haven't seen a better explanation of how to use those features to achieve this. It's one of the few examples I've read about that embraced hot code reloading in order to maintain uptime.
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.
I was making a loose analogy to get the point across and also used the phrase "abstract machine model" for a reason.
> It's more like Java -> Kotlin
Not quite true either. If you want to do the analogy of a VM-based language the BEAM is not just a VM like the JVM. It plus the rest of the ERTS is an AOS.
> Not really. You can get quite far in Elixir without knowing any Erlang.
True. But eventually when you do want to go outside of the Elixir ecosystem you need Erlang to access the BEAM facilities.
The point was that Erlang is the "native language" of the "Erlang AOS" and is worth knowing whether you prefer Elixir/whatever on BEAM.
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.
For the question of "which language should I use, should I use Elixir?", I think it's valid to evaluate it against "all the other ecosystems that solve the same problems differently".
If you want to design a bespoke solution from scratch, then it could make sense to use a single ecosystem, that avoids the complexity of Kubernetes et al.
So it really depends on your use case.
If you're designing independent software, like RabbitMQ, it might make sense.
It's not bad, it's just that other solutions are often better.
But you haven't justified why the "normal" solutions are better. That's all that I'm asking for—if k8s deployment is better than hot swapping on a distributed BEAM VM, then explain why, don't just say that the BEAM is worse because it is different.
But it seems that I misread the original question. I see now that it reads "should I be using Elixir for new projects or Erlang?". There was a linebreak after "new projects", so it only read to me as "should I be using Elixir for new projects".
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.
It's an interesting topic, but it seems that presenting an opposing viewpoint is generally downvoted on Hackernews (and likely other social media), so I'm not sure it's worth spending the time.
My position is pragmatic, from a managerial economics perspective, of maximizing value and reducing risk. I suspect that Elixir attracts a fair amount of language enthusiasts, who are somewhat biased when they evaluated the business value of a language choice.
WhatsApp/Discord is a very specific use case, of needing a high number of concurrent users that expect real-time messages when to the same session (e.g. chat/chatroom, "Bob is typing...").
AFAIK, BEAM excels at immutability (lots of reads, like readers in a chatroom) and concurrency (vertical scalability).
So those are not appropriate reference use cases for the typical user.
BEAM is notoriously slow, and has been bottom-ranking in Techempower benchmarks.
Although that seems to have improved in recent years.
