For a technology organization to say that it is polyglot is one of those hot “new” catch-phrases. Why is this something that organizations strive for, and what are the ramifications of actually being polyglot?
Benefits
One of the most commonly offered benefits of polyglot is that teams can choose the language that best fits the problem they are trying to solve. I suppose this means that if you need to develop something that needs to be very fast in an embedded system, you have the freedom to choose a low-level language like C, or whatever the hardware may support. At the same time, if you need to develop a backend server for some REST APIs, you may be free to choose something like Java. This can go much deeper than the broad category of problems. Requirements such as needing to dynamically execute client-written code, memory footprint, BPEL support, streaming processing, etc. can all play a role in the reasons to choose multiple programming languages inside a system.
Those big category language selections are usually not what organizations mean when they talk about being polyglot. Almost everybody has those kind of natural language selections; we typically write the client-side code in a different language than the back-end server, and some embedded systems demand a certain language flavor that you don’t want in the rest of your ecosystem. The “smaller”, closer-to-the-business questions are the ones that tend to drive the polyglot discussion. This is the area where multiple languages tend to make sense for the big category problem, but perhaps some subset of those languages have features that would make developing the new widget much easier or faster.
Polyglot also helps to attract developers. If some of your services are in Java, you can hire the Java developers, but they will also need to learn Ruby and work on some of your Ruby services too. Your developers say they are happier, because they can choose whatever language (within reason) they want to work in. They do still have to support that crappy old stuff written in the language that was so last year though.
Drawbacks
That leads into some of the problems with a polyglot system. Some developers just don’t want to learn new languages; they are perfectly happy continuing to work in Java, and would rather leave than have to work on that thing over there written in Go. With too many languages that a team is supporting, there ends up being no expertise in any of them, and the team ends up getting plagued by problems that they just don’t have a deep enough knowledge of the language to fix.
Moving people around teams can be more difficult, if this team uses Go and that team uses C#, there will be a large learning curve for the new team member. Frameworks and supporting services don’t cross over. Security scans and tools need to keep up with the number of languages used. Governance becomes harder.
It seems like organizations that “go polyglot” end up going down that route for a while, and then start to backtrack. The benefits they initially got from polyglot start to be overwhelmed by other concerns. Sometimes they just go back to the single language that was the starting point, but more commonly they become bilingual or perhaps trilingual. I think that is what polyglot ends up being most of the time. It becomes too much of a weight to spread out to more than a couple of languages for an organization to continue to support all of them.