DEV Community

loading...

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

Collapse
m50d profile image
Michael Donaghy

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.