Kotlin is a very tame language choice, in what I assume is a very Java heavy organization. Peers should be accountable for learning new languages and following the implementers rule.
nah, this is just the brilliant hacker type mentality (individual over team, parachute in and rewrite everything in today's cool language) type stuff that gets really annoying once you're responsible for a set of interconnected components of software that matter.
it's critical to root out these hero types lest they ruin your organization with hand grenades wrapped up as "refactored" projects using the latest language. seniors won't put up with this, and rightfully so: it basically raises a middle finger to the organization's previous culture/work, and they are now responsible for doing it... again. it's disrepectful and ought to be a fireable offense, ideally rooted out in the first few weeks when the new team member is given some slightly autonomous tasks.
It seems to me that the real problem is hiring engineers who only know one language and rest on that language choice for their entire career. If you build an organization of engineers with a versatile set of skills then there is no such thing as a wrong language choice.
Mandate the standardization of interfaces rather than languages and you empower all types of developers in your organization.
I have no issues with the language other than hiring pool is pretty small.
Unfortunately letting something like this sit means you have a huge time bomb of tech debt that only one person can work on. It is a liability for the company and long term profitability.
Any Java engineer worth their salt should be able to use a JVM derivative. If you hire people who are capable of using multiple languages then you won't have an organization of people restricted to a single language.. and the problem is gone.
it's critical to root out these hero types lest they ruin your organization with hand grenades wrapped up as "refactored" projects using the latest language. seniors won't put up with this, and rightfully so: it basically raises a middle finger to the organization's previous culture/work, and they are now responsible for doing it... again. it's disrepectful and ought to be a fireable offense, ideally rooted out in the first few weeks when the new team member is given some slightly autonomous tasks.