Ask HN: Should orgs limit the number of languages/frameworks?

Handle proposing a new language or framework the same as any other proposal: figure out the benefits and drawbacks, and decide if the former outweigh the latter.

Adding a new language or framework to an existing organization has big drawbacks: it requires developers to learn it, adds complexity overhead, and if the project using it integrates with any other projects, well, integration between most languages and frameworks isn't very good. If the organization is already using several languages and frameworks, presumably they cover a wide-range of use-cases, so they're less likely to encounter a new use-case that only a new language or framework solves.

But I'd strongly suggest not to implement a fixed "company will use N languages and M frameworks max", because it depends on the situation. It's similar to enforcing strict coding conventions (e.g. "variable names should be between N and M characters", "functions should be under N LOC", etc.). Sometimes there is a good reason to write unconventional code, and similarly, sometimes there is a good reason to add a new language, no matter how high the number of already-used languages is.

Very typical and probably the most important takeaway: these things are almost never decided by technical merit.

Almost any organization, once it reaches a certain size, ends up thinking about standardizing on languages and technologies, and put in place certain systems to support the preferred choices and discourage others.

Whenever the subject is revisited, it tends to end up as a political fight at the management level, and technical folks don't have much say. Even when a company does have set standards, if the project is important enough to be visible at a high enough level, the technology choice can go against the standards.

In one case I'm aware of, a shop that was heavily Microsoft/C#/TS/Azure chose Go and K8S for a high-visibility project, despite almost no one in the company knowing those technologies, and the few who did could not be pulled away from their existing work.

Unless you have a really good reason to, stick to a few programming languages.

Hypothetically let's say F# Guru gets hired. They're the only ones who really knows it. They program a key system in it, then quit.

Who maintains all this F# code.

Agreed - I worked for a company that had no restrictions so there was Java, C#, C++, Python, JavaScript, TypeScript, CoffeeScript, Go, Ruby, Scala, Lua for various different bits and pieces (as well as some more esoteric stuff like a niche database that there very few developers for). I think things kind of worked because the different choices were restricted to very siloed teams but... hardly ideal.

Letting languages be a free for all is a terrible decision for an org of any size.

1. The more languages and frameworks, the more things need to be updated. The number of security upgrades you find yourself doing scales linearly with the number of runtimes you support.

2. If you can't share business logic, you're wasting time. Gluing two microservices together because the logic you need is in another codebase is infinitely more complex than just importing/copying/submoduling what you need.

3. You're not gonna support all those languages forever. Maybe two will survive. The champions of whatever one off project you have will leave, and that code will languish. You will pay the cost of rewriting that code.

4. There's really no issue with "the right tool for the job." All the languages can do all the things if you wield them correctly. The first version of Uber was written in PHP. There's no strategic advantage to picking a language for one specific project: pick your languages to support the needs of all your future projects.

5. Your greatest bottleneck is going to be people. Hiring and keeping good people is and will always be the hardest task you encounter. If you rush it, you get bad people. You simply cannot hire enough people who are either polyglots or of such quantity that you can dedicate them to each one off project in its own special language.

6. You will eventually need to start scanning for security issues. Multiply the complexity of that by the number of languages and frameworks you use. Explain to your general counsel and CFO why is so slow and costly to do an audit.