You sure we don't work at the same place? :)
Hiring is nearly impossible, come support our legacy system, and what ever you do, don't introduce Erlang into any other part of the company. Why? We feel burnt on this one project, and god forbid we get any deeper than we are now. What this isn't appealing?
[dead]
That's generally decided by the experience of the existing team members.
... whom an inexperienced hiring department entirely trust when they assure that the technologies they are already familiar with are the best fit for the company, let's hire only people who think the same?
I'm not sure if you're being obtuse. But rewriting your stack in a language no one on the team knows because someone on HN said it's a better fit for your usecase is something no good engineers/managers would think is a good idea. If a potential hire thought that was a reasonable thing to do, that would be a major red flag - a sign this person lacks experience, and any kind of business understanding.
It depends, if a potential hire suggests using Python instead of R or Java to process data, that's a reasonable proposal.
Caught me as an odd choice to scale an IoT backend.
at some point you end up with path dependence -- you're in the situation you're in, and it would be big-bang rewrite or incremental migration to port all the code to a new stack, not to mention the costs of retraining existing staff to be able to effectively develop in and support the new stack, or replacing the staff with different staff who know the new stack but don't understand the existing business and code. so maybe the previous decision to pick tech stack A over tech stack B when starting the product was pretty sound given the circumstances, or maybe it wasn't, but it doesn't matter that much from the perspective of deciding what to do next.
Oh yeah, I know all too well about path dependence. That's how we end up with a Rails monolith that's written in a very standard/structured way so that many devs can contribute, add type annotations for safely/docs, etc. Using no types is like having no tests and thinking about adding them later. Usually better to have it in place as you go.
Erlang / Elixir are languages that are easy to begin learning, but difficult to master. In our case, the team was able to get the basics up and running quickly, but the service became increasingly difficult to manage as our product requirements expanded beyond the strengths of the Erlang ecosystem's core competencies.
In our case, the original team of developers was excited to write a greenfield service in Erlang, but much less excited to maintain and scale it long-term. Some of them used their experience to speak at Erlang conferences, which led to them being recruited away by companies who were desperate for Erlang developers to maintain their legacy code after the core team left. Ironic.
At first we tried to train existing engineers on Erlang. Doesn't work. Not because Erlang is bad, but because people don't want their companies changing the direction of their career development just to support someone else's legacy project that requires an on-call team to support.
So your two options are: Hire at least 2, preferably 3 Erlang engineers for the reasons discussed above. Harder than it sounds, because AFAICT there are a lot of companies with 2010-era Erlang backends that made sense at the time but now require dedicated maintenance engineers.
Or you can rewrite it in a more common language, which is the route we chose. Rewrites are a difficult decision for well-known reasons, but ultimately it was the correct choice. Being able to drop 10+ engineers into a project as needed is a huge accelerator compared to funneling 100% of your work through the 2 Erlang gurus in the corner who maintain a codebase that no one else wants to touch.