The answer to both situations is "No" and "No". Many engineering managers have a difficult time saying "no", to the detriment of the business.

We are building a product for customers, not a playground or post-graduate program. There are legitimate reasons to add another language but they must be evaluated with the needs of the business in mind, these include long-term maintenance costs and hiring/training costs regarding new/esoteric skill sets, among others.

This sounds great in theory, and in companies that I personally own I am able to achieve this level of control (mostly). However in my experience on the battlefield you rarely have the luxury of this level of absolute control.

Surely there's a middle ground? Plenty of good companies allow for fun experimentation. However, I also wouldn't say that switching to a new language or frame work that may boost long term productivity and hiring effectiveness is considered a playground

If I read "good companies" to mean those that have enough excess resources to make lots of foolish mistakes, then yes, totally agree.

"Keeping devs happy" by itself is a terrible reason to introduce a new language. If your developers cannot find happiness by working together and building something great, you have bigger problems.

> If your developers cannot find happiness by working together and building something great

Just a friendly reminder that there are lots of different kinds of people who approach their work differently. Not being "business-driven" isn't necessarily a bad thing.

sure but wouldn't you agree that being in business at all, and not unemployed, is a bigger thing, and that the luxury to play is earned by success. if you can't pay people including yourself, I suppose you can always stay at home and play/experiment all you want.

It depends on your perspective. Different people are motivated by different aspects of engineering – lots of folks simply like "playing" as you put it, and the business's bottom line isn't important (except insofar as the business can employ them).

From the business's perspective, they want the best engineers they can get, regardless of the engineer's motivations — as long as they can get them to provide enough value to the business, it can be worth some trade-offs like having hackweeks, etc. It's the business's job to align the incentives of their workers, and sometimes this includes throwing them a bone in choosing a preferred language, even though it may not be the most efficient.

Making foolish mistakes aka learning?

Talent retention is needed tp be considered also. Engineers do want opportinitues to learn new things and experiment. If you're too draconian you might see top engineers leaving or moral being low with discontent engineers who might in turn be less productive.

There are always interesting problems to solve and new technologies and solutions to use. That fun definitely never ends. But a whole new language (not counting small glue/config languages/json dialects/etc), a new source base for the team, one must be cautious (and they always start small, more temptingly). It's a potentially huge and maybe not great investment being pitched. Do your due diligence.

> as a back-burner project without official approval.

Can't this be seen as evaluation of a language?

Or you acquire a company that had a different set of approved languages. Do you throw their tech away and rebuild from scratch? No. N+M languages.