Funny how these things are fairly simple on BEAM. Funny how majority of industry won’t ever learn anything about BEAM and will keep hitting walls for the rest of their careers.
Without evaluating the merits of your statement, I find it funny you start out implying others are close-minded, but end up rather close-minded yourself.
Considering how many other solutions that are all trying to solve distributed systems issues but avoiding just using Erlang or Elixir I think the statement has merit.
Exactly, I've commented many times on here that at least half the show hn posts (like Hatchet from yesterday) are just overlycomplex implementations of features that have existed on the beam for decades. Or at least already in the Erlang/Elixir ecosystem (Oban, for example).
Proof that the only thing that matters about any software is whether it's easy for beginners to get into. What's wrong with Erlang that in ten years it's seen so little adoption?
The majority of the industry is made of people who care mostly about their own careers. If solving nasty distributed system problems is simple, you can't justify having a huge bloated expensive team. If your team doesn't spend a lot of money, you aren't seen as very important within the company. Since people want to be important, it's hard to get more productive languages to be adopted.
It's way too slow and per-task overhead is much higher than in compiled alternatives (Rust and .NET - BEAM performance is much worse than these, sometimes by a factor of 10).
Surely you're not asserting that other platforms that provide concurrency and parallelism primitives are designed by people who don't know what they're doing?
It's not so much that it does things others can't, it's that it does all the things, running in the same application space, and things like background jobs, or a caching layer, or cron are all things that most stacks these days need to sort via another library, and Erlang/Elixir apps just do it all on BEAM.
I find the pedagogy of Erlang and Elixir to be sparse. Maybe those programmers just start out strong and don’t need soft on-ramps. I know they’re working on it but not having types is also a big deal for project scalability and not just performance scalability.
