I don't think so. Kotlin is an unmaintainable soup of features: it can match all the selling-point examples of Scala but only by adding ad-hoc special cases for each one. (For example, Kotlin has null safety and it lets you write code using errors-as-values style "either" types - but it has two completely separate syntaxes for these things, and so it's impossible to interoperate or reuse code between those two approaches). In practice Kotlin codebases still use magical incomprehensible reflection (Spring Boot) and magical compile-time manipulation (Kapt), so you have the worst of both Java and Scala worlds.
Are you sure you're not confusing Kotlin with Scala?
> For example, Kotlin has null safety and it lets you write code using errors-as-values style "either" types - but it has two completely separate syntaxes for these things, and so it's impossible to interoperate or reuse code between those two approaches
And that is a problem how? Stick to one style.
> In practice Kotlin codebases still use magical incomprehensible reflection (Spring Boot)
Switching an API from "a result or nothing" to "a result or an error message" happens all the time, and switching in the other direction is only slightly less frequent. And of course most programs have some APIs where one is appropriate and some where the other is. So consistency is valuable.
I'm arguing my lived experience of working on Kotlin codebases. It's not about the specific framework, it's that people always use a framework that breaks the rules of the language, just like in Java, because the language itself isn't expressive enough. Whereas the thing that makes all those complex Scala libraries worthwhile is that they enable you to make a whole enterprise-scale codebase using just plain functions and values.
