I'm a long time Java user. If you are not using Kotlin at this point, you are doing it wrong. That's of course a blunt/provocative statement and there are of course perfectly good reasons for continuing to use Java on some projects. However, most of those reasons are non technical. And I'd argue that 1) Kotlin is a drop in replacement in those projects 2) it's running far ahead in terms of language features that aren't even on the roadmap for inclusion in Java (which in all fairness has been slowly catching up over the last few releases) 3) you can introduce it gradually. A small tweak to the build file and you are good to go and ready to start converting code. You can have your first Kotlin file building along with your Java code in under 30 minutes; even if you've never used Kotlin before. That's how I did it. I was committing ported tests within 2 hours on my first attempt to use the language and would recommend that as a great way to get started.

People confuse Kotlin for an Android specific thing, which is a mistake that arises from the fact that all of the above is doubly true on Android. Google more or less stopped bothering to keep their version of Java up to date after Java 6/7 (they did fix some glaring features) because of the whole debacle with Oracle. This meant that Java on Android was a getting kind of stale and klunky many years ago. And as Kotlin was designed as a drop in replacement for Java, people just started using it way before it was on Google's radar and way before it was anywhere close to 1.0. It just worked and vastly improved people's lives on Android when Google had very little to offer to make life better. Of course it helped that the main IDE for Android is made by Jetbrains (Kotlin was created by them) which meant the tooling was there early on. Google eventually acknowledged that this was obviously better without any downsides and endorsed it as the preferred language for Android a few years ago.

The same is now happening for backend development. E.g. Spring started endorsing Kotlin two years ago (around the release of Spring 5) . Kotlin works perfectly fine with earlier versions of course but as of Spring 5 there are lots of Kotlin specific things in the framework and the upcoming versions are adding loads more of Kotlin friendly features. The net result of this is that there is a huge accelerating shift from Java to Kotlin that has been ongoing for a few years now.

I'm bringing this up because Kotlin is one of the fastest growing languages out there and most of that growth is at the cost of Java. A lot of jobs advertised as Java are in fact Kotlin jobs.

So, Python isn't claiming as many Java developers as the article suggests. Of course it is experiencing rapid growth from e.g. data science projects and it's always been a popular language.

I recently was on a python project (as in just a few weeks ago). So, I'm in position to compare. I've always liked python for certain tasks. Python 3 has definitely moved in the right direction (e.g. adding types) but I do think the editing and refactoring experience in e.g. VS Code is lagging behind a little compared to other languages I've also used recently (e.g. typescript, go). MS actually only added python tooling just a few versions ago (so the out of the box experience is better since then). And of course the Intellij/Kotlin combo blows any of those out of the water in terms of utility. It's not even fair to compare it to that.

But what I like is that python code is comparatively simple for some things. This has always been a big reason for it's popularity. Performance was never a reason to use python and the tooling wasn't either but the language ergonomics have always been a big plus. I'd argue Go is a natural upgrade that shares some of those characteristics but comes with better tooling and performance (at the cost of syntactical compromises). E.g. the vs-code experience for Go is comparatively awesome. Kotlin is IMHO nicer to deal with overall but currently not great for e.g. command line stuff or small microservices/lambdas mainly because of the run-time footprint. And while Graal and Kotlin native are fixing that, neither is easy to deal with currently. The Kotlin native compiler has not been finalized yet and Graal with Kotlin is a combination of experimental, mostly unsupported, and incompatible with many frameworks out there. This is a temporary inconvenience and IMHO the next boost in Kotlin endorsement will come in 1-2 years when those issues will hopefully have been addressed.