Hacker News new | ask | show | jobs
by tadfisher 147 days ago
This is needlessly divisive. JetBrains does not owe two-way interop to the Java ecosystem.

There are many Kotlin features that do not have clean interop with Java; Compose, coroutines, and value classes come to mind. And it turns out that this mostly benefits Java, because these features are not built with the kind of engineering rigor that Java language features enjoy, and some of these features would behave way better with support in the VM anyway.

Where it makes sense, they are already moving closer to Java/JVM-native feature implementations; for example, data classes already have two-way support via records, and value classes are almost there (waiting on Valhalla GA).

Besides, wouldn't you want this stuff represented in the Java type system anyway? Otherwise you get the Lombok problem, where you have this build dependency that refuses to go away and becomes a de facto part of the language. Result<T, E> is not quite the same as rich errors which explicitly are not representable by user types.

3 comments

I know it is divisive, yet many Kotlin folks don't appreciate the platform that makes their ecosystem possible in first place.

From all the JVM guest languages, possibly fostered by Android team, they are the most anti-Java ecosystem.

Clojure folks appreciate being a hosted language, Scala is kind of they would rather have Haskell but still JVM is kind of cool, Groovy was usually a way to script applications.

Kotlin, well those behave as if ever the JVM would be one day rewriten in Kotlin, they have Android for that.

The features you mention will never be supported in Android by the way, at least I don't believe Google will ever bother to do so.

I view the relationship between Kotlin and Java like that between C++ and C.

The two-way interop is one of Kotlin's advantages as it makes porting code from Java to Kotlin easier, or using existing Java libraries. For example, you don't have/need something like Scala's `asJava` and `asScala` mappers as the language/standard library does that mapping for you.

The interop isn't always perfect or clean due to the differences in the languages. But that's similar to writing virtual function tables in C -- you can do it, and have interop between C and C++ (such as with COM) but you often end up exposing internal details.

> JetBrains does not owe two-way interop to the Java ecosystem.

They owe their users and customers. Many of them are asking for this and were lead to believe it was a priority when adopting the language.

> This is needlessly divisive. JetBrains does not owe two-way interop to the Java ecosystem.

It does. The language literally started as a “better Java” and has been marketed so for years until they’ve pivoted towards multi platform.