|
|
|
|
|
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. |
|
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.