[simon_void]

Rich Errors look promising to me, but what about interop with Java? What will the return-type of a function be on the Java side be, if the return type on Kotlin side is: Int | ParseError | SomeOtherError?

Background: unions aren't restricted to one normal type and one error type, but to one normal type and any number of error types, so this can't be modelled as syntactic sugar on top of an implicit Either/Result type, can it??

[pianoben]

> what about interop with Java?

From the proposal discussion[0], the runtime representation on the JVM will just be `Object`.

[0]: https://github.com/Kotlin/KEEP/discussions/447#discussioncom...

[ubertaco]

Oof. That's pretty gross: just throw away all typesafety?

A `Result<T, E>` return type is way better.

This feels like it'll be viewed like Java's `Date` class: a mistake to be avoided.

[pjmlp]

Kotlin folks seem to mostly care about Java as bootstrap to their own ecosystem.

The anti-Java bias, against the platform that made it possible in first place and got JetBrains a business, is quite strong on Android, fostered by the team own attitude usually using legacy Java samples vs Kotlin.

[tadfisher]

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.

[pianoben]

Android folks have good reason to have anti-Java bias. Their bias, as it happens, is against old Java, which they are constrained to use as fallout from the Oracle lawsuits of yore. Kotlin breathed new life into Android in a meaningful way.

On backend teams, I've not personally encountered much anti-JVM bias - people seem to love the platform, but not necessarily the language.

(yes I know there's desugaring that brings a little bit of contemporary Java to Android by compiling new constructs into older bytecode, but it's piecemeal and not a general solution)

[rileymichael]

by default it'll be exposed as a `java.lang.Object` and they've thought about using compiler plugins to generate methods returning `Optional<>` or `Result<>` instead

https://www.youtube.com/watch?v=IUrA3mDSWZQ&t=2626s

[simon_void]

thank you for the link to the talk! I actually witnessed the talk live, but must have completely missed this or simply forgot that this was answered :D

[dingi]

They only care about Java -> Kotlin integration. Not the other way around. It has been like this for a long time. Looks like an extractive relationship to me to be frank.

[tadfisher]

Anyone who is writing Kotlin libraries to be consumed by Java code is going to either avoid this feature or write wrapper functions for better Java interop. There is no reason to accuse language designers of lock-in by designing features that don't have a clear equivalent on every possible foreign interop target.

[rhdunn]

Kotlin does have interop with Java, but is limited by either the features not existing in Java (non-nullable types) or behave differently in Java (records, etc.).

You have to explicitly annotate that a Kotlin data class is a Java record due to the limitations Java has on records compared to data classes [1]. This is similar to adding nullable/not-null annotations in Java that are mapped to Kotlin's nullable/non-nullable types.

Where there is a clean 1-1 mapping and you are targeting the appropriate version of Java, the Kotlin compiler will emit the appropriate Java bytecode.

[1] https://kotlinlang.org/docs/jvm-records.html#declare-records...