It taught me way more about sales and adoption than anything else.
As a former Erlang developer it never ceases to amaze me that an entire language, standard library, toolchain, and runtime that's entirely dedicated to and on-paper perfectly technically suited for the most pervasive "backend" development challenges of our time somehow managed to effectively blow a 20-year technological headstart and failed to leverage the notoriety that should have come from several super high-profile "trendy" commercial use cases in the 2006-2013'ish era. Such that it's still relegated to general obscurity and is seeing its core competencies taken over by a hodgepodge of other languages and technologies that started much later but became rapidly more popular while also still arguably doing a worse job at those things than Erlang did.
Erlang could be the literal silver bullet and people wouldn't use it because it's a funny looking language.
I showed it to all my developer friends back around 2008 (I found out about it because a competitor used it and open sourced some of their stuff) and the only comments I ever got was how weird it looked. No one gave a shit about anything else. The story it told me wasn't about sales, it was about how shallow most developers are.
Once nodejs came out it was the final nail in the coffin - callback hell solves all your problems, no funny looking language necessary!
As nice as the beam might be, erlang is just not a great language by the judgment of many people, including me. Elixir can't make up for it either. I refuse to use a dynamically typed language for anything bigger than a couple hundred lines.
On the JVM you have languages like Clojure and Scala, which both are top class in their domains imho. I wish there was the same for the beam.
There is the ever going war between dynamically vs statically typed. I can only conclude that this comes down to personal preference, but maybe also a bit experience (since I would prefer to work with Clojure over Java even for a big project any day).
I simply like to put in a lot of focus during certain times to make the compiler understand what I'm trying to do and then go to "autopilot" later and have the compiler tell me exactly all the places I have to change (and often how) when I implement something new or fix a bug.
I think it's mostly trading some problems for others. I work mostly with static typing but prefer dynamic typing, and I don't feel that static typing offers much benefit for most programs I work on.
I actually really enjoy the assertive style of Elixir/Erlang. I think that while they are dynamically typed languages, the assertive style rests somewhere between dynamic and static typing, and in fact offers some safety benefits over your average statically typed language: while you don't get it at compile time, this idiomatic code offers benefits at runtime that most people don't bother with in other languages.
> I don't feel that static typing offers much benefit for most programs I work on.
Maybe for example you have a good memory and I don't (I certainly don't). I forget things so quickly that it's always a huge hassle for me to be productive when I have to use e.g. python. That's just one example, there are surely other different traits of people that make them prefer one over the other.
Another one is that I really hate to write documentation and tests, except for very highlevel ones (UATs and high level documentation). The reason is that it gets outdated quickly and I don't like to keep it aligned. With types, they are automatically always aligned (the compiler forces me to) and it's easy to do so because there's lots of tooling for refactoring types.
Maybe other people actually like that part of the job and hence don't feel that a typesystem is helping them much.
As a former Erlang developer it never ceases to amaze me that an entire language, standard library, toolchain, and runtime that's entirely dedicated to and on-paper perfectly technically suited for the most pervasive "backend" development challenges of our time somehow managed to effectively blow a 20-year technological headstart and failed to leverage the notoriety that should have come from several super high-profile "trendy" commercial use cases in the 2006-2013'ish era. Such that it's still relegated to general obscurity and is seeing its core competencies taken over by a hodgepodge of other languages and technologies that started much later but became rapidly more popular while also still arguably doing a worse job at those things than Erlang did.