[lmm]

This is less and less true as Java evolves. For example Java streams expect you to use Optionals to represent absence, which means they interoperate awkwardly with Kotlin which expects you to use Kotlin nullable types to represent absence. Another example: Kotlin has gone through multiple rounds of different ways of doing async, none of which is compatible with Java's new fiber implementation, so they'll either have to go through yet another incompatible rewrite of how they do async or be more incompatible with future Java libraries.

Subjectively, a lot of Kotlin features are implemented in a kind of ad-hoc way because they're designed to be as easy to use up-front as possible, at the cost of consistency. So the language has a kind of "technical debt" - it's hard to evolve it in the future. Add in the fact that the language lacks the higher-level abstraction facilities that would let you work around these incompatibilities (e.g. Scala has its own Option that's different from Java Optional - but this isn't a big problem because you can write a generic function that works on both. But you can't write a function Kotlin that works on both Java Optionals and Kotlin nullable types), and I'm really skeptical about its future.

[Alupis]

Personally, I find Java's Optional to be kludgy and annoying to use.

An extension value clears this up in my Kotlin code, something like:

    val <T> Optional<T>.value: T? get() = orElse(null)

Allows you to do:

    repository
        .findByFoo(bar)
        .value
        ?.doSomething()

Slightly ugly, but allows you to gracefully unwrap Java Optional's into something Kotlin understands.

Regarding project loom and coroutines - I don't see why loom won't work in Kotlin codebases as-is. The change would be made in the corountines library, not user codebase.

[lmm]

> An extension value clears this up in my Kotlin code, something like:

You can convert at a boundary, which is fine if you have a line between Java and Kotlin parts of your codebase. But you can't seamlessly mix Java and Kotlin and use the same functions with both, which is what some Kotlin advocates try to claim.

> Regarding project loom and coroutines - I don't see why loom won't work in Kotlin codebases as-is. The change would be made in the corountines library, not user codebase.

I would bet they'll need incompatible changes, because there are subtle differences in the models. (Or they could keep the same API but with subtly different thread safety guarantees - but that would be a whole lot worse, breaking existing code in nondeterministic ways).