Linux announced that Rust would be the second official language supported in the codebase. That's impressive, considering Linux has been around for 30 years! Engineering discipline.
Only five-ish* languages are approved to use within Google (Java, C++, Go, JavaScript/TypeScript, and Python, as I recall). Languages like Haskell or frameworks like Node.js are forbidden. Why?
More languages means more tooling and workflows to support. More institutional knowledge needs to be shared and more specialists to be hired. In many cases, even with service-oriented architectures, code-sharing can be difficult. The same is true of frameworks. For example, using React, Angular, and Svelte across different projects in the same company can be a maintenance nightmare.
Many developers have the intuition to stick to a minimal viable framework within a project. For example, it doesn't make sense to have an application half Ruby on Rails and half Django. But engineering leaders should resist the urge for toolchain sprawl. Django indeed is one of the best frameworks for admin tools. But if every other project is already built using Rails, it might not make sense to take on the burden of having to integrate a new language.
The technical debt of supporting a new language can creep up in many unexpected places. For developers, there's learning new compilers, updating build systems, and installing new linters and formatters. For DevOps, there's CI and CD, which might need to be rewritten: test agents need to be updated with the new toolchain, and another package management system to be updated and secured. Repositories need to be separated (or monorepo tooling built for multi-language projects (hard!)), and code-sharing needs to be put behind APIs. API clients might even need to be autogenerated for multiple languages.
The toolchain sprawl applies to frameworks too. Wire formats – JSON vs. Protobuf vs. Thrift vs. XML. Configuration formats – JSON vs. YAML vs. XML. Build tools – Make vs. Webpack vs. Bazel.
There's no right answer to these questions. Even if there was a right answer, it would change over time. But the more your choices differ between projects, the more likely you're sitting on heaps of technical debt. So avoid toolchain sprawl. It might seem like it slows down engineering velocity initially, but on the organizational level, it will make your life much easier.
*countless scripting languages and configuration languages are used as well. But getting any of these approved is a lengthy process.