A lot of really brilliant folks have written truly shit Elixir code because they underestimated the challenge. Oh you’re passing that blob to four different gen servers? Cool expect you blew out your memory copying terms between them. It’s also operationally complex and doesn’t like the normal way of doing things because quite frankly it’ll do it better.
Take metrics or logging, both will slow down your application in Elixir/Erlang/BEAM by a not insignificant amount but people just shovel as much as they can into their apps assuming truths from other languages still hold. When your request times are measured in microseconds, that instrumentation is gonna slow you down. People literally buried boxes with erlang on them in the ground and they’ve worked for 20 years. Maybe give sampling a shot if it worked for a telecom maybe it’ll work for your blog :p
I’ll stop rambling here. While I truly love elixir it’s a lot more of a rodeo than people expect and it extremely subtle ways. It’s also extremely expensive to hire developers. Because you’re not going to be able to hire juniors. They just don’t exist for a language like Elixir.
I think people who have difficulty with some of the constructs at the just-inside-the-defmodule scope are not understanding concept #3
I believe there is more a "critical mass" coupled with "matter of taste" issue, which I hope will be solved as more good stuff comes out (e.g. graphing support via Vegalite for Livebook as announced yesterday https://twitter.com/dashbit/status/1395763964215185409).
I believe a number of people would currently like to get paid to work with Elixir, and hope the critical mass will be reached soon.
No particular problems hiring - finding fantastic devs is always hard, but lots of people we hired were attracted by the language.
The second problem is bigger than the first.
For hiring, I worked at a company running Erlang for our main server app; very few people were hired with Erlang knowledge, almost everyone had to learn it on the job. As an earlyish hire, I had the most experience before being hired because I sort of remembered seeing a Slashdot post when Ericsson open sourced it; but I didn't do anything with it until I was hired. The couple of big issues this lead to is we never really did anything useful with the OTP application concept, no releases and what not, just hotloading with l/1 in the shell; and maybe it took us a bit longer to figure out how to scale BEAM because we didn't have anyone with that experience... But BEAM is written so nicely that people with experience optimizing C stuff can dig in and optimize BEAM without a huge learning curve, and most of the bottlenecks fit the same pattern of something simple that works fine at reasonable volume, but blows up consistently and clearly when you run it at large volume, so pretty soon you learn the pattern and know what to look for... And of course 24 has a lot less of these bottlenecks than r14 did.
My personal favorite Elixir gotchas I've witnessed are, trying to run Mnesia on only 2 nodes, and OOMKiller doing interesting things where somehow parts of your app die.