We started out with Python/Django monolith when we had less than 10 developers. Then the team chose Golang for a new service to have better performance. At that time we had about 25-30 engineers.<p>Then the company hired some people who have Erlang and Ruby background. So they decided to use Elixir for a couple of new services.<p>Now we have about 120 engineers and half of us are doing backend. Another team recently decided to use Scala for a service they were building.<p>It seems to me that people tend to choose their favorite language/framework and argue that we should be using 'the right tool for the job'.<p>According to Edmound Lau who wrote Effective Engineer book, we should be using the least number of tools so that our operational burden will be low and we can have impact.<p>What do people think of number of languages that are optimal for backend these days?
The problems with too many programming languages are: (1) it is harder for somebody to jump in at an arbitrary place, which is particularly bad for maintenance, where it is not unusual that a "simple" bug fix requires changes to parts written in multiple languages and (2) code frequently winds up being duplicated, both of the "business rules" variety and of the system and technology specific kind.<p>As an example of the latter, consider a service written in Go that may need stubs written for it in several other languages.<p>I have seen the cost of polyglot development to be high in teams up to 20 or so developers. When you have 120 developers it less reasonable to expect that one person can jump in anywhere, so the reasons for multiple languages multiplying will eventually overwhelm the coherence benefit of using a minimal number of languages.<p>Occasionally too there really is a "right tool for the job" or rather right tools for different jobs. Most of the commercial NLP devs I know who have a codebase they work on use both Python and Java since there are many great libs in both languages.