[somekyle2]

I've been on teams responsible for components written in more niche, powerful languages by previous employees who were deep in that particular language community. The author was really smart, the code was good. It was a big headache. First off, different build setup, different runtime, couldn't use most of our standard libs, so it was an island. It being in a language most people didn't know well meant it mostly only got updated as necessary; we certainly had people who could read the code and make tweaks with some comfort, but it was mostly just tweaks because nobody had the depth to really engage with the high level design idioms. It being a niche lang/community, it moved fast, so after a year or so our tool was apparently using deprecated practices; in our supported languages, teams did large-scale fixup across repos for new versions, but this being a special lang/toolchain, it was on us. Eventually, I believe it got rewritten, somewhat simpler, in one of our supported languages, and it was fine.

Maybe this is a success story: someone made a useful tool in a weird language and we used it successfully for at least a year. Maybe it wouldn't have been made or would've been worse or more expensive if they'd been forced to write it in a supported language. Maybe it would've needed to be rewritten anyway.

My view is a simple one; as one of the leads responsible for it, it was a special case bit of code, something people tried to avoid touching. Nothing about it required a niche language technically, so the added difficulty of working around that was friction and risk. It wasn't that people couldn't learn the language; they could, we had lang PhDs. It's just better if you can keep people where they have existing expertise, and spend your learning points on solving problems users care about.

[OkayPhysicist]

I don't think "avoid otherwise-unused languages for secondary tools" is the same as "avoid less common languages for your main product". Every software developer at your company will likely work on your main product for a non-trivial amount of time. Any software developer who can't figure out a new language in a trivial amount of time isn't worth hiring. Thus, everyone you hire will eventually be competent in the language of your main product.

In contrast, for secondary products, there's a good chance most developers will never work on it at all, and of those who do a significant fraction will spend only a trivial amount of time. Adding the overhead of working in a new language to that balance is significant.

Therefore, the ideal is "Choose the best language for your main product, then write all supporting software either in that language, or a widely-used lingua franca like Python".