Q: How Much of "the Kotlin Way" Is the Right Way?

Soon enough, tools, libraries, and frameworks started appearing, having perfectly working equivalents in Java, but written in "idiomatic Kotlin".

Mmm, what is the point of being citizens of the JVM and being interoperable if you end up rewriting stuff that already exists just because of ego? (Because I suspect ego is in play here :D).

Could there be legitimate reasons to rewrite something? Do they go faster if written in Kotlin? I don't know anything about it so I might be missing something. Because if the only reason is "I don't know Java, so I'm rewriting this in Kotlin" that seems very weak (and also it means you're likely going to introduce bugs and solve issues that were already solved in the first place :D)

I started wondering where I had seen this before 🤔.

ehhe

The general answer to rewriting libs in idiomatic kotlin is often to provide a more concise API for kotlin consumers. In many cases this could be achieved just writing extension methods and many libraries fall in this category such as core Android having many kotlin extensions, gson being another example. The strong uptick in libs lately is for kotlin MPP which I believe provides what you really want. Kotlin can provide the cross platform foundation and existing libraries on target platforms can help acceleration of development. For instance writing code that runs on node, android, and iOS. In this case you will end up using many platform specific libraries which is terrific while also mixing in new libs that simplify multiplatform.

Well, I think it's completely okay to make things the idiomatic way. There are certain things that, while perfectly working in Java, are simply too cumbersome to use and can be vastly improved. My favourite example of this is the new Android KTX that are basically extension methods over what already exists.

Like this:

view.viewTreeObserver.addOnPreDrawListener(
    object : ViewTreeObserver.OnPreDrawListener {
        override fun onPreDraw(): Boolean {
            viewTreeObserver.removeOnPreDrawListener(this)
            actionToBeTriggered()
            return true
        }
    }
)

Versus this:

view.doOnPreDraw {
     actionToBeTriggered()
}

So of course, the Java way works perfectly, but it's also a pain in the ass to write. Isn't it why Kotlin was made in the first place? If everything was great with Java I don't think there was any reason for Scala or Kotlin to exist.

I think this is really important. I will die on the hill that Kotlin is more enjoyable to develop with compared to Java, but I don't think we need to reinvent the wheel just to do it "the Kotlin way".

A great example comes from my own experience at my current employer. We have a BaseActivity class that is in Java, that could be shortened a lot by switching to Kotlin. We would get null safety, we would be able to use a when instead of if/else, but we haven't converted the file.

We haven't converted it, because it works fine, and we rarely touch this file to begin with. If we reached a limitation in Java, or we found ourselves touching this file regularly to the point that we'd benefit from using Kotlin, that might be a different story. However, I feel that with this file and in some of the examples you're referencing yourself, that's just not the case.

Mmh, that's a very valid point.
There is no single answer IMHO.

Sometimes it's useful to reinvent the wheel and to break with the Java world.
Coroutines is probably the best example.
Kotlintest is so much better than junit.
DI in pure Kotlin is so much simpler than dagger.

Generally the best approach is more to add on top of the existing Java library the few things that makes it nice to use from Kotlin.

The logic of making it nicer for Kotlin can definitely be pushed too far. Kotlinpoet for example has all those builders to make it usable from Java. Ain't that obsolete and clumsy? I thought so. Not anymore. It's not a big deal in practice. Not splitting communities is more important.

kotlin should have never been created, because scala exists. of course it's going to get its own libraries and grow a new ecosystem. better just to come over to scala, because we've already figured out most of the hard stuff the kotlin-using kiddies will be discovering soon

Many existing Java libraries are written in ways that make them impractical to use from code that follows modern good practice (whether you call that practice "functional", "SOLID", "idiomatic kotlin", "idiomatic Scala", or something else). It's good to write replacements that are more amenable to a better code style, and this isn't really a Java-versus-Kotlin problem - I've seen the same thing happen in Python where people write new libraries that offer the same functionality as existing libraries but in a more functional-idiomatic way.

This does mean the pitch for Kotlin was always based on a lie though. Scala already offered perfect JVM interop, but this isn't and will never be enough to bridge the gap between a mutation-oriented ecosystem and the style that we now realise is better. Kotlin was always doomed to become either a trivial syntactic sugar over Java, or a language that offered substantial benefits but at the cost of forking out a separate ecosystem, exactly as Scala did and for exactly the same reasons.

Of course Kotlin is now in the same place that Scala was 5-10 years ago - the same choices still have the same results, and it's impossible to deliver the benefits of Scala without paying the same costs. Being 5 years behind Scala is not such a bad place to be, but you're better off in today's Scala, and likely always will be.

Use whatever you like. Kotlin make it easy to use existing no kotlin code kotlin way by writing some extensions and so on... You don't need to rewrite library, just add some code for it.

Porting to Kotlin also gains you multi-platform code sharing. I'm highly motivated to port existing Java domain models and serialization DTOs into Kotlin so that I can build an iOS framework from it.