But this also might be a problem of a company not providing any improvement / career prospects for your programmers.

If working as a programmer means sticking to C# or Visual Basic or Python codebase and just working on adding new features or new business logic to your application for years and years, many engineers will not find that fulfilling. The best engineers will always want to learn about new tech and approaches (dev ops, containers, PaaS, automation, new languages and tools, AI / machine learning etc).

You cannot blame them for leaving. What you should instead do is provide interesting challenges for them, if they want to use some new technology, work on finding a justifiable use case that management will approve for it.

I understand that for a company that treats tech as a cost centre this approach makes sense but then they can't wonder when best engineers keep leaving to proper tech companies that do actual R&D and where they can become best engineers they can be.

You need to allow your best programmers to learn new tech and progress in their career or else they'll eventually leave for greener pastures and you'll be left with mediocre people who are content and don't want to learn new things.

It's like that analogy I have heard over and over again.

CFO asking CTO: What happens if we invest in developing / training our people and they leave?

CEO replies: What happens if we don't and they stay?

This has nothing to do with whether engineering is a "cost center" or not. It's about fundamentally what is important about the practice of engineering. Whether to use Python or Go or Java or Rust or whatever is rarely anything other than bike shedding. In those cases where it's not, the key problems are rarely which language is technically better: more often the problems are associated with labor supply and how well the proposed language' ecosystem plays with existing implementations'.

To be fair I've been on the underling side of that where I wanted to build some new server we needed in a new language (coincidentally, Golang), but it was honestly just for curiosity/shits&giggles. It became somewhat of a running gag for ~5 years where every new service we needed I'd suggest Golang.

I'm a senior engineer and I'm also the person that wants to use the shiny new thing.

I'm just learning Go and I'm itching to find a project to use it on. It's super hard to justify it though when C# or Python would work just as well and those are languages that we already use.

The best time to do it is on a new project or component of an existing system, in my opinion. It doesn't make it a good idea, but it can be a nice way to introduce something new and possibly more productive.