Elixir is a niche (that's the truth). Also in the article it is written 'Relatively difficult to "recruit" developers with existing experience in Elixir'.
Why would a SW company invest in niche languages where the resources (software developers) are really expensive and really hard to get? Technologically it's all great but economically that's a nightmare.
I have been involved with bringing it to my company as the primary proponent. The truth is it hasn't been hard to teach people it and they can produce decent code pretty quickly and good code a bit longer than that but still acceptable.
We have found a few people who knew it already and were looking for a job, but that is fairly rare. Instead, we know we can bring people up to speed on it quickly and also it signals to people that we're willing to give them some language options (Ruby or Elixir) within some boundaries. Having these options is good for ownership of an area.
I don't think it is that black and white. I have heard from some companies adopting Elixir that hiring became easier because the demand for their previous technology was really high and they could differentiate themselves with Elixir.
There are also companies that we really successful in hiring by reaching out to functional communities in general. And of course, there are also companies struggling to hire Elixir developers compared to other techs. YMMV.
The only times I see this argued is from suits looking to treat programmers as a fungible resource. This is never a problem for companies looking to retain people.
If your status quo is working programmers as long as you can without a raise until they switch jobs, a niche language is a threat. If you re-evaluate your staff based on their experience gained, you can head off the churn.
I think this is too harsh. A company can establish an enjoyable and empowering culture, that attracts and supports talented developers — and can still try to avoid hiring obstacles at the same time. It might not have been what therealmarv meant in his post, but your comment makes it sound mutually exclusive.
As a counter-argument: I've experienced several times that "niche tech" companies offered non-competitive salary packages and perks, because they offered the cool tech instead; "sure, we can't match that other offer, but we built our stack on that language/tech that is so hot right now".
Not arguing about the quality of Elixir, just about the gatekeeping that happens in this thread.
If you have a solid background in software development, it's not too hard to become proficient in Elixir in a few weeks. If you recruit good talent with a demonstrated proficiency and willingness to learn, you will be fine. If you need to switch languages or systems in the future, these devs will still be of great use to you.
Ok, that sounds good. My overall experience is only for most companies (I'm working as a contractor for many years) that they don't really want to invest in you. Either you fit for the job or not (and competition is not easy sometimes).
I can’t argue with this point in general, but your first question was from the perspective of a company. There certainly are companies, that are willing to use things like Elixir (like my company for example) because we believe that an experienced developer should be able to come up to speed quickly with Elixir. What really takes the time is learning our business domain and our existing codebase. Or looking at it another way, I wouldn’t want to hire someone that was a Rails dev, I would want to hire someone that was a strong dev in general and may have happened to be doing Rails most recently.
Something I'd also mention is, with Elixir, you'll get your MVP done maybe 10% slower than you would in Ruby.
The difference is, in Ruby, after 2-3 months, you'll be rewriting large portions of what you did to get there. And in another year or two, you'll find yourself being blocked by earlier designs not for a day or two, but by a month of work or better.
In Elixir, you simply will not experience that. Even if written poorly, it's easy to rework/change, and you probably won't need to anyway because it's just easier to get things done without painting yourself into a corner.
Doesn't that depend a lot on the project? Only one datapoint, of course, but we have an elixir project at work and it's in dire need of a refractor. The dynamic nature of the language doesn't help.
Thing is, it's not 100% dynamic. It's compiled, so most common refactor errors will be revealed by that alone(no function named, not the right number of arguments, etc). The harder to find things would be harder to find in most typed languages too, unless you had tests to point them out to you.
That's one of the things you lose when going from Erlang to Elixir. Sure the macros are useful and convenient, but they also make the code less explicit and harder to refactor. There's probably a reason why Erlang for the past 30 years had no macros, despite being a homoiconic language.
TLDR: try working with Erlang if you find your Elixir code-base in need of a refactor - chances are you'll learn conventions which will help you write more maintainable code in Elixir, too.
Why would a SW company invest in niche languages where the resources (software developers) are really expensive and really hard to get? Technologically it's all great but economically that's a nightmare.