> So how about don't be stupid about it and instead make three engineers devote 1/3 of their time to this?
If your product-critical cloud backend depends on people being knowledgeable in a specific programming language, you don't make it a 1/3 time side project for multiple engineers.
Also, if you start giving people "1/3 time" responsibilities, you're one step away from "everything is top priority" territory.
The point is: If you're going to write critical pieces of your infrastructure in a specific language, it's a requirement to have at least one person full-time dedicated to that piece of infrastructure.
When things go wrong at scale, you can't depend on a group of people for whom this is a part-time side project.
My least favorite part about HN is trying to share advice based on real-world experience, only to people show up and armchair quarterback the situation with solutions that sound easy on paper.
You'll have to trust me that we didn't just throw our hands up in the air when dealing with the Erlang situation. We tried a lot of the suggestions here and more.
Erlang is one of those languages that, for whatever reason, lulls engineers into a false expectation that they can pick it up over a few weekends and start knocking out IoT-scale solutions serving 6- and 7-figure connection counts. Speaking from direct experience, that's not only untrue, but it's a dangerous misconception that leads to a lot of pitfalls.
Don't get me wrong, Erlang is great if your problem set matches up neatly to core OTP functionality and well-defined patterns, but you don't have to stray far until you start finding difficult pitfalls that aren't easily addressed by engineers learning Erlang on the fly.
Sorry if I wasn't clear. I'm not questioning why you switched from an otherwise unused technology. Sometimes it's the best way forward. My comment is meant for this sentence:
> Also, if you start giving people "1/3 time" responsibilities, you're one step away from "everything is top priority" territory.
I like to maintain and improve legacy systems and usually happy to do it. When I got a separate side-project I had constantly fight with my team why I should work on project X instead of contributing to our core project. If it was my whole team responsibility they were happy that somebody does it. Also, they wanted to invest enough time so it won't break.
If your product-critical cloud backend depends on people being knowledgeable in a specific programming language, you don't make it a 1/3 time side project for multiple engineers.
Also, if you start giving people "1/3 time" responsibilities, you're one step away from "everything is top priority" territory.
The point is: If you're going to write critical pieces of your infrastructure in a specific language, it's a requirement to have at least one person full-time dedicated to that piece of infrastructure.
When things go wrong at scale, you can't depend on a group of people for whom this is a part-time side project.