Kotlin <-> Java interop is a totally optional topic you could have skipped over, telling you as a Kotlin developer (who recently had to switch to .NET because Ukrainian job market is fucked up). besides, Java itself isn't that hard if it's Java 17 or newer, and it's rather good if it's Java 25 or newer

> Kotlin <-> Java interop is a totally optional topic you could have skipped over

This is the same place F# has been stuck in. It’s a great language on its own, but you can’t just use F#. Every F# must also do C# interop. It’s too 100% optional in theory, but never in practice. The best CLR/JVM libraries for anything are Java/C# ones. You need to interop with them to develop practical Kotlin/F# applications. You can limit yourself to the Kotlin/F# ones, but then you’re artificially limiting yourself to experimental libraries at best. You will find yourself needing a charting library, a DNS library, an SMTP library, an AWS SDK or a rabbitmq SDK. The best ones are gonna be Java/C#. Yes, you can always find a random GitHub repo for a “Kotlin-native X”, but the Java X library is a thousand times more mature, stable, performant, feature rich, etc. Same problem with F#. And the “glue” code is so “straight forward”, why would any one bother?

I have quite literally never had to do Java interop in my Kotlin work. Do you have an example?

In contrast, your statement about F# strikes me as mostly true - albeit my interop was always the other way around (consuming F# code from C#).

Calling Koltin co-routines directly from Java code, as an example.

There is a reason Android team has Java friendly guidelines.

Kotlin also has its own features that differ from the way the JVM or Java has decided to develop them. For example: coroutines vs virtual threads or Kotlin “value” classes and Java value classes. The semantics don’t match and Kotlin stops becoming simply a “better Java”.

That is the curse of guest languages, see C and C++ as well.

That is why I always say keep with the platform, and why despite my endless rants on C, I keep myself up-to-date in regards to it.

Eventually they always diverge.

It'll be interesting long term to see where they go with Kotlin. WRT value classes they'll probably introduce something like @JvmValue like the did with @JvmRecord when data classes diverged from Java records.

They behave as if JVM was only relevant to bootstrap Kotlin ecosystem, especially since they became Google's darling on Android, and doubled down on Kotlin Multiplatform.

From all guest languages on the JVM, the Kotlin community is the one I rather avoid, as many behave thankless to the platform that actually makes their toy possible in first place.

Clojure, Groovy and even Scala, focus primarily on being nice with Java and having a symbiotic relationship.

Koltin folks are like "we're replacing Java, ahaha stupid language".

Well where is the Kotlin Virtual Machine, other than Android userspace, which nonetheless requires Java support to benefit from Maven Central ecosystem?

Certainly driven by Android folks, I would say.

Clojure also "comes with the baggage" of learning Java libraries.

And JavaScript comes with the baggage of learning about web browsers and NodeJS's "fs" module.

Kotlin is a terrible language for learning, as it has a lot syntactic shortcuts that are easy to mistake for magic. I think it's actually easier to learn some Java first, as it's simpler and teaches you the semantics both languages (mostly) share.