Yet another myth that comes from not working in big companies... Learning a language is mostly useless for several reasons: 1) You will be among the only person who is willing to learn it 2) You will have no capable reviewers, and usually you need about 2 for each CR 3) Your team has no production knowledge and muscle memory for that language. Ergo pretty much all you do will be garbage for a very long time and a huge operational risk. 4) Other teams at your company will not know this language either.

Bottom line: Pick the language most teams at your company are familiar with. At Amazon that simply is Java for anything that is not frontend, period. Even getting into Kotlin presents a major obstacle. Clojure? Yeah right.

Edit: Just to clarify. Working in a big company is not meant as a restriction. In fact, having worked in several startups before, these would do well to adopt the same principles for programming and prohibit this "university graduate" way of developing software. In the end, if your startup is going to survive, it's going to become a big company itself someday.

Oh, I am learning clojure. As best I can and as quickly as I can. But that isn't the problem so much as clojure's ability to make code so succinct that to read it, you have to sit down and really, really read it.

But see, someday, I won't be on this team anymore. And then all the time I spent all learning how this beast works will be wasted and some new person will be scratching their head at it.

The vast majority of devs can be (some definition) of productive in general languages like C#, Java, Python etc in a day or a few. As in, able to grasp code, spot and fix logic faults.

That is far from accurate for more left-field languages. Should every new hire spend three months meditating and becoming one with the functional gods? Seems a bit silly, almost as silly as trying to hire a programmer that is a fit into the company, and knows the relevant domain AND programming language/ paradigm as dictated by someone long gone.