Erlang is a way better fit for a distributed agent orchestration layer. You have a ton of dependencies, over network and maybe in userspace, you have a lot of inter-operability and reliability constraints, you want to hotswap code and capabilities at runtime, without degrading the overall system performance. And you get networking/distribution/async message passing for free
I consider myself an expert in this relatively niche domain and welcome follow up, critiques, and even your most challenging problems. I love this area and I think distributed systems are coming back in a big way in this new era!
It doesn't feel different enough to merit a difference. Elixir is just a set of Erlang macros that turn one syntax into .beam that otherwise wouldn't turn into .beam
Elixir is way more productive to write/deal with (Phoenix vs. Erlang templating) maybe if you're a web dev, but at the end of the day you're dealing with the same exact same underlying architecture. If you're a prolog programmer, Erlang will feel nicer than if you're a ruby programmer.
I have many packages published as Mix packages, and some published as rebar packages.
Overall, ergonomics definitely feel nicer with Elixir, but I feel like by having it be portrayed as "so different" from Erlang, people don't pull open the Erlang/OTP docs, and don't look at the dozens of behaviors that already exist that usually solve your problem.
Like, why is there a gen stage in Elixir but not in Erlang?
If you wanna use the BEAM, you can use it. If they were more in sync, and provided OOTB in the same distribution, I'd always lean towards Elixir.
Just feels weird that Elixir gets a bunch of street cred for what are fundamentally Erlang/OTP capabilities
Elixir has a better developer experience, or at least it's more approachable. Better code splitting with modules, easier to use variables (no var, var1, var2), loops that look like loops but easy enough to fall back to recursion, and an easier to read syntax.
gen_stage is just a library. One could write it in Erlang. It's like asking why Broadway is only for Elixir and not Erlang.
It was hard to approach the Erlang docs when I started in Elixir. However, they've moved to an ex_doc format (is it ex_docs?) as a standard and it's so much easier to grok.
>Just feels weird that Elixir gets a bunch of street cred for what are fundamentally Erlang/OTP capabilities
I know what you mean, at the same time I'm thinking we should welcome any momentum from the Elixir community. The more people working with Elixir/Erlang the better. And if you try Elixir at some point you learn about the Elixir background.
An anecdote which may be of interest. Speaking to Elixir and Erlang developers I found those who started with Erlang preferred its syntax while those who started with Elixir or didn't know either preferred the Elixir syntax.
While I think there is some truth to that regarding the programming paradigm, I always felt the EVM have two big drawbacks, compared to something like Go:
1. Requiring a VM, making deployment more complex.
2. Not being natively compiled, or always having this performance roof for the inner loops.
After considering both Erlang/Elixir and Go a lot for my scientific workflow manager, I finally went with Go for these exact reasons.
It already does well coordinating IoT networks. It's probably one of the most underestimated systems.
The Elixir community has been working hard to be able to run models directly within BEAM, and recently, have added the capability for running Python directly.
https://github.com/arthurcolle/agents.erl
I consider myself an expert in this relatively niche domain and welcome follow up, critiques, and even your most challenging problems. I love this area and I think distributed systems are coming back in a big way in this new era!