Kotlin's null safety is a huge win, but the language has it's own set of flaws such that I try to avoid using it.
The language's "declarative style lambda syntax" makes code overly-complex. Every library is basically it's own DSL and every lambda context has it's own set of specialized keywords. If I write `test { somthing(value) }`, depending on the context, `somthing` could be invoking a higher-order function, calling a method on an object that the lambda is extending, or calling a static method. The muddling of data/declarations and procedures, makes jumping into new codebases confusing and time-consuming. Rich Hickey has pointed out in numerous talks that syntax itself is complex because rules and order are complex, but in languages we generally trade a little complexity for terseness. Kotlin encourages this trade-off far too much in the direction of complexity, and the language would be almost unusable if not for it's IDE support.
Getting to the root of the previous problem is that method extensions in general feel like an anti-pattern. Without introspecting a method call, it's not possible to tell where that functionality is coming from. It's a huge amount of added cognitive strain to have a classes functionality split into various files, possibly across various code bases.
Another problem is coroutines (oh joy, another new DSL to learn). By now, it should be known, from languages like Go and Erlang, that preemptive lightweight threading is almost always going to be better than cooperative. It avoids function coloring, keeps throughput of applications more consistent, and is generally easier to reason about. Java also now has preemptive lightweight threading via virtual threads, but because much of the Kotlin ecosystem is reliant on the coroutine API, it don't get any of the ergonomic benefits.
The language's "declarative style lambda syntax" makes code overly-complex. Every library is basically it's own DSL and every lambda context has it's own set of specialized keywords. If I write `test { somthing(value) }`, depending on the context, `somthing` could be invoking a higher-order function, calling a method on an object that the lambda is extending, or calling a static method. The muddling of data/declarations and procedures, makes jumping into new codebases confusing and time-consuming. Rich Hickey has pointed out in numerous talks that syntax itself is complex because rules and order are complex, but in languages we generally trade a little complexity for terseness. Kotlin encourages this trade-off far too much in the direction of complexity, and the language would be almost unusable if not for it's IDE support.
Getting to the root of the previous problem is that method extensions in general feel like an anti-pattern. Without introspecting a method call, it's not possible to tell where that functionality is coming from. It's a huge amount of added cognitive strain to have a classes functionality split into various files, possibly across various code bases.
Another problem is coroutines (oh joy, another new DSL to learn). By now, it should be known, from languages like Go and Erlang, that preemptive lightweight threading is almost always going to be better than cooperative. It avoids function coloring, keeps throughput of applications more consistent, and is generally easier to reason about. Java also now has preemptive lightweight threading via virtual threads, but because much of the Kotlin ecosystem is reliant on the coroutine API, it don't get any of the ergonomic benefits.