The case for language agnostic hiring

For most of the popular languages used throughout business this is somewhat true, they have quite similar designs and goals and a team can get by with one person who really knows the language and its ecosystem. There is still years of experience in a language, its packages and tooling (especially in certain languages) that is hard to get any other way so I don't think its simple.

But I also think there are languages that different enough that there is more bending of the brain to do and the fundamentals of how you approach programming change and so that broad base has to include a broad church of languages. Its not enough to learn C#, Java, Python and Ruby because they are all pretty similar in fundamental style, Haskell is going to be a big shift as is Rust, but Go is going to be easy. What languages you come from is going to matter, a team using lisp for a decent sized project is going to be a tough entry for anyone new as they will have developed their own language within it and each concept must be learnt painstakingly with experience and time.

I am just not convinced that language knowledge is irrelevant, certainly throughout my career its been important and I have regularly been able to solve problems others could not because I knew something existed which while obscure has its uses. I don't think its all that quick to learn the languages APIs completely let alone all the primary open source packages and further still open source tooling both quickly and properly. There is a real chance you get stuck at advanced beginner with surface knowledge of everything to do with a language if you don't realise it goes deeper.

Yes and no. The thing is, it's not just the syntactic features of the language. The features of a language (type system, memory and resource management, scoping rules, concurrency model) deeply affect the kind of programming style one adopts. The tooling and the library ecosystem require a considerable time investment, too.

Perhaps if workers were treated and paid better, they'd have less incentive to leave every two years.

Elixir, Haskell et al. require concepts that are not required at all in e.g. Java. The functional programming module at my university had the highest failure rate after the math and statistics classes.

Even something like C can require new concepts. I was a tutor for a university C programming course and students that had no problems with Java struggled hard with direct memory manipulation, pointer arithmetic etc., because those were foreign concepts at that point.

You can't expect Devs to self-teach each other those concepts on the side, that (advanced into their studies, third-year) CS students struggle with hard. If you want your OOP Devs to learn e.g. functional programing, you have to give them dedicated (paid) time for this, IMO.

Agree, but also not every language is equal in that regard. Switching from writing perf-oriented C# code to Rust is fairly easy - concepts like async/await, stack/heap, ref/references, iterators, expression trees and generic constraints - all of them translate well. Switching from Python or Ruby to C# or Java however - not so much. The more languages have common concepts between them, the better. Migrating from a more powerful language is usually, if frustrating, much easier than the other way around.