I'd love to see the internal explanation on how hiring kotlin for BE devs is easier than hiring elixir devs.
That's like trying to pivot from finding unicorn to finding pegasus.
That's like trying to pivot from finding unicorn to finding pegasus.
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.
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.
It’s not really that hard.
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.
IOW you really want senior people, full stop.
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!
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.
Both sound like major dysfunctional problems.
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.
Right now I'm working with a team where we're trying to introduce FP and reactive programming, and most of them have never heard of either one, or if they have, have never really used it.
[0]: https://tauri.app/
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.
Its all about the tradeoffs you're going after. If you absolutely need to cut down errors to a minimum and are willing to sacrifice developer speed/productivity, Haskell with IHP is certainly a compelling offer. (yes I know an experienced haskell dev will probably be jsut as productive as a experienced elixir dev but it will take much longer to train someone from another language to haskell than to elixir.)
conversely, if you want speed at all costs, rust is certainly nice.
now if we're talking Pareto efficient intersection of performance, developer productivity and maintainability, yea elixir hits that sweet spot well. I haven't encountered a language that does that better yet. Python comes close if you're willing to take a drastic hit on performance. The tooling is descent, the day to day ergonomics let me focus on solving our startup's problems rather than wrestling with the platform. It's not perfect (lord knows I wish there were more libraries).
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.
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.
(I am an Elixir dev)
Its existence hardly matters on the JVM world.
I interviewed a company a while back that was using elixir which I thought was cool, but I ended up not taking the job. Part of what worried me was realizing just how much they struggled to find interested candidates, and it seemed like they were willing to compromise to hire as a result. Perhaps I was a compromise, haha.
The CTO and other devs on the team painted a bleak picture of building the team, and elixir seemed to be the main obstacle.
The other issue they faced, though I doubt it was as much of an obstacle, was that they were working on pet insurance. That was a major deterrent for me. The compensation and working conditions were excellent though, so I suspect many people wouldn’t care and would gladly take the compensation and flexible work life – were it not for elixir.
I found it surprising but I’ve seen people work on worse things for less money using more popular languages. Perhaps more people are afraid to learn something new than it seems.
Definitely sounds like someone overspent their innovation tokens:
I have no idea about Elixir but it doesn’t look as conventional.
Scala or Clojure, on the other side, is more radically different.