I consulted for 3 months at a OldBrickAndMorterBank in Chicago. 100+ year old that had gone 100 years outsourcing IT and decided it was time to start bringing IT in house. The project I was involved, one of many, about 50 developers, primarily contractors from large contracting houses (did I say 'bring in house' -- well having the project managed in-house was what that meant, not the 'cogs'). They had bought into 'full agile, CI/CD microservice end to end' and the whole project was Kotlin/SpringBoot. None of the developers had ever used kotlin before, but it was never an issue. At a training class I asked about their experience and skills with kotlin. The general self-assessment was 'moderate' -- i.e. they felt their own skills in kotlin were 'average' -- . I was tasked to do performance analysis and architecture review. The interesting-to-me takeaway -- was that the fact that kotlin was used was rarely mentioned and never an issue. There was tremendous issues with the project as a whole -- but none of it was related to the language. Performance issues were largely niece misapplication of microservice patterns and a methodology designed to guaranteed that good ideas were thwarted before they could infect others, agile stories refined to the level of single cells in a spreadsheet, data formats chosen based on familiarity not applicability, piles of dead code untouched lest it decrease the numeric value of unit tests passed.
But where there were no problems whatsoever, nor much discussion -- was kotlin. The developers had no problems at all learning and using it consistantly in a large project. Defects due to things like array bounds, null pointers, incorrect type or signature, language or function performance etc -- simply non existant.
that left room for the Really Big Problems -- of which there were many. But kotlin ? no. it was a no-brainer, non-issue.
no difficulty hiring nor using at scale.