In a large orga, you limit the languages available for projects to well supported ones internally, ie. to those that are known to have a port of the RPC/metrics/status/discovery library. Also makes it easier to have everything under a single build system, under a single set of code styles, etc.
If some developers want to use some new language, they have to first in put in the effort by a) demonstrating the business case of using a new language and allocating resources to integrate it into the ecosystem b) porting all the shared codebase to that new language.
Absolutely. I was thinking what if there's a good business reason to use a different language that's not the norm for your org. Then you're stuck with an infra problem preventing you from using the right tool for the job.
Of course, this is the exception to the rule you described well :)
I don't think of it as an infra problem, but as an early manifestation of effort that would arise later on, anyway: long-term maintenance of that new language. You need people who know the language to integrate it well with the rest of the codebase, people who can perform maintenance on language-related tasks, people who can train other people on this language, ... These are all problems you'd have later on, but are usually handwaved away as trivial.
Throughout my career nearly every single company I've worked in had That One Codebase written by That One Brilliant Programmer in That One Weird Language that no-one maintains because the original author since left, the language turns out to be dead and because it's extremely expensive to hire or train more people to grok that language just for this project.
There are only 5 languages. JavaScript, C++, Java, Python, C#
This is basically the same set of languages people were writing 20 years ago and will probably be the same set of languages people will write in 20 years from now.
It really depends on your domain. I haven't seen C# a lot, nor python, in some orgs.
For some (like me), it's more a superset of C, assembly, bash, maybe lisp, python and matlab.
For others, it's going to be JavaScript, PHP, CSS, HTML..
I agree though that a library is usually domain-specific, and that you can probably easily identify the subset of languages that you really need official bindings for (thereby making my comment a bit useless, sorry for the noise).
If some developers want to use some new language, they have to first in put in the effort by a) demonstrating the business case of using a new language and allocating resources to integrate it into the ecosystem b) porting all the shared codebase to that new language.