The tooling an docs all guide you in the right direction and usually code in the wild aims to be straightforward.
I’ve really never had trouble onboarding people to Elixir unless they had started learning it solo as a Ruby dev, then they typically have to unlearn some stuff.
Functional programming gets really hard when you try doing stuff like state and IO monads. Elixir in contrast gives you genservers for state which is very simple by comparison as well as having dead simple IO. you don't have to make special functions marked as IO or use any type of exotic type theory.
TLDR: yes Elixir is functional but its the 80% that is easy to learn. you don't have to bother with that last 20% of functional programming rabbit hole crazy town.
source: me with 6 years of elixir experience and having built the entire backend for my startup in elixir over the last 3 years. Elixir is s a platform that fits a nice sweet spot where you need to knock something out fast and still have something reasonably maintainable (and refactorable) that also happens to be really fast(performance wise) for the level of day to day developer productivity you get.
The problem was actually getting the stuff deployed or running into weird niche issues that require a couple days to fix. I was a bit out of comfort level at that point but the exaws sdk’s, confex, releases, supervisors. Made me really appreciate how much more support and just easier mode/python has been in my current job.
Reason I'm asking is because I love this attitude and I think it works so long as your team will provide the support for someone to ramp up, but I seldom see these kind of job posts saying we're fine if you learn the stack.
IMO, everyone needs to learn a from of stuff for every job. Thus understanding of high-level concepts and ability to learn are paramount. If you tell me though that your primary language is XYZ and you cannot answer basic challenges with it we encounter during the interview then that's a really bad sign even if I don't care much about that actual language.
(I am an Elixir dev)
I'm currently doing a ton of C# work and it's great - my relevant professional background is basically all C++, with some Java in the very distant past.
Even if you can, you then have to solve the issue of keeping a department stocked full of senior devs happy when you have limited promotion/perk/raise options and so churn will likely be relatively high even in a healthy environment.
It's a nice fantasy view of the market as an ideal world simulation but does not reflect the reality of hiring software engineers.
If you're dealing with concurrency and distributed systems at medium to high scale you really want your senior people to be familiar with the language.
Sure, each language has different tools to solve corresponding issues, but I prefer to understand the problem I am solving to intimately knowing the tools I need to use.
Ofc, having both is perfect!
IOW you really want senior people, full stop.
I've written my first application level thread/concurrency library for DOS in the 80s. So you can count me as experienced. In my opinion as long as one is senior developer and knows the subject language does not mean fuck all as long as it adequate and language / libraries support needed primitives. I've written distributed middleware with multithreading / concurrency in many languages including ones I did not know before starting the project.
