| 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. |