Aside from my doubts about the way this is measured, is it even a good strategy to simply chase the currently "most popular" languages?
A few years ago I shared an office with three aged graybeards who sat in a corner and spent 3 half-days per week silently working on legacy COBOL systems. I thought they were something of a joke, and said so when a person with insight into their invoicing was present. They corrected my impression.
Aside from "the right tool for the right job" kind of conversation, there's one inherent aspect to chasing the most popular language (given that you find an actual ranking that's put up meaningfully, which I don't think the TIOBE index is): you may find more people able and willing to work with it, which can sometimes be a feature.
I've been in a company which had a major refactor need, and they took the opportunity to slowly convert their backend from PHP to Go* because they couldn't find any good PHP developer (let alone any willing to work in PHP). For the actual project, it kinda worked, but for the recruitment, it went from not having any applicants / very mediocre people, to having way more people applying, and a few competent ones in that pool.
* As to whether that was the right choice, that's a completely different topic...
Sort of. Chasing the latest everything is always a bad thing. Chasing ONE latest anything may be a good thing. Staying to far back can be a big negative - COBOL may pay the bills, but you will have a hard time hiring someone willing to work with it, and there are some things we have learned since COBOL that really are worth having.
You should always keep an eye out on what is happening elsewhere. Sometimes those things are enough better you should switch. Sometimes those things are better but you should just add them to what you have. If you write COBOL you should be writing the 2023 version today which has a lot of things not in the original 1959 version (what I don't know what since I don't write COBOL).
There is a cost to switching/rewriting everything. There is a cost to whatever downsides of your language/frameworks have. The other language/framework options also have their own downsides - often they are unknown. Most of the problems you are having are not caused by the language, rewriting to a better architecture in the current language would solve a lot of problems (I recommend you put the money for a big rewrite into a refactor in place effort, the costs long term is similar, but you are always shippable which means if budgets are a concern you can scale back and extend the schedule)
If the language is popular that is a big advantage. I can teach you whatever programming language you choose to use, but if the language you choose is popular you can hire "experts" while if the language is unique you will spend years training people before they are experts. This is a big advantage of something popular.
I agree this is not a good strategy, but I found it curious that Kotlin seems to have stalled and maybe is even declining. After all, it really seems what many developers would like Java to be. The article also mentions the existence of better alternatives in the form of some other languages' cross-platform frameworks, but doesn't make any concrete example. Anyone has ideas on which frameworks those could be?
Btw, Kotlin isn't platform-specific as they seems to say in the article, it's cross-platform as well.
> After all, it really seems what many developers would like Java to be.
As a backend Kotlin developer, I wonder if a lot of the advantages that Kotlin used to have over Java are rendered moot by new features in recent versions of Java.
It may not be that Kotlin is declining in general but rather mobile development using it (and Swift) is declining which is the dominant case. If we could see non-mobile Kotlin use that would be an interesting trend to see. I imagine some of the adoption and familiarity could carry over to backend uses.
A few years ago I shared an office with three aged graybeards who sat in a corner and spent 3 half-days per week silently working on legacy COBOL systems. I thought they were something of a joke, and said so when a person with insight into their invoicing was present. They corrected my impression.