This comment reinforces my perception that erlang is less popular than it should be because engineers are not as strong as they should be.
The advantages of erlang, over basically every other language, make the "cost" of learning the syntax very low relative to the value of the erlang language.
If you think of yourself as a good engineer, you shouldn't be following the crowd of blubs who use languages simply because they don't tax their brain to learn them.
I have long been fascinated by the principles of business management, specifically those in the well known book "The E-Myth".
The idea is that it is easier to grow and scale a business if every role is reduced to something achievable by the lowest common denominator. The book cites McDonalds as an example and how they specify the exact location of pickles on a burger to make sure that a 15 year old can produce burgers indistinguishable from their peers. Sure, plenty of people can cook a better burger than McDonalds, but anyone can cook a McDonalds burger given the equipment and instructions.
In terms of programming, a similar approach may well exist. I've seen it in two forms. First is the enterprise strategy. Standardize on simple, yet inefficient technologies. Anyone with X credential can be as productive as anyone else (this works well because nobody is very productive so its a low bar). This makes hiring and firing much simpler.
The second approach is the "hire smart people and provide them with the tools they need to learn and succeed." I've personally seen great success with "Welcome to the company, let's learn Erlang."
As an engineer who enjoys being challenged I prefer the latter, but I'm not convinced that the first strategy is a bad one from the business's perspective.
Ostensibly, this is what has propped up PHP. Of course calling those who you can convince to absorb a different syntax as "smart" is just a psychological lock-in strategy, rather than an effective sieve.
Not in my experience. I once helped build a team of Elixir developers. There were few people who knew elixir at the time. That simple filter ended up getting us a really great team-- much better than interviewing a bunch of applicants from with other language backgrounds-- the people who wanted to learn elixir, knew it, or were interested in it, were much better than average.
In fact, that's the only effective filter I've found for interviewing.
Our evaluation of "smart" is independent of syntax absorption. It's less that we convince them to absorb a different syntax, more like we select for people who wouldn't get hung up on it.
The advantages of erlang, over basically every other language, make the "cost" of learning the syntax very low relative to the value of the erlang language.
If you think of yourself as a good engineer, you shouldn't be following the crowd of blubs who use languages simply because they don't tax their brain to learn them.