Is Kotlin an evolutionary dead end?

And this is good. If Java ever catches up to say 80% of Kotlin’s code readability (my personal measurement), I’ll consider returning to it. For now it is very far from that, so I use java only if I have to. We’ll see what the future brings.

The Java equivalent would be:
final var something = obj.getValue();

The “Filter, map etc creates intermediate arrays for each operation.” that one baffled me from the beginning. That is just a weird design decision and by looking at the code you cannot see what is going on.
My personal biggest issue is that now everything is ‘val’ No types no nothing, just magic.
And Less is More does not work with Kotlin. I fear the day when they will add parameter type overloading and the mouth of abuse that will come from it…

This is a weird design decision from the perspective of someone who has more exposure to imperative code. It is perfectly natural in the functional world.

Also, for now this is a kind of technical limitation of Kotlin. We can either transform collections, so materialize intermediary results and do multiple loops. Or we can transform sequences, so use only a single loop and no intermediary results, but we then have to perform a lot of function calls, which in many cases is even slower than the first option.

So yes, currently “transform APIs” don’t provide a direct equivalent of the classic loop. If it bothers you, your only option is to use a loop or wait until the technical limitation will be solved (but I don’t know if there are any plans for it).

Why is it an issue for you? Being a overly type-explicit was one of the biggest issues with Java for many, many years. Slowly, Java improves in this matter: in Java 7 they introduced the diamond operator, Java 8 introduced lambdas where we can often skip argument types, since Java 9 we have methods like List.of(), so we can infer items type easily, finally Java 10 added var which is similar to val/var in Kotlin.

Kotlin is still a statically-typed language. We are not obliged to type everything explicitly, because the compiler can infer it for us in many cases. Still, we can type it directly if we like and sometimes it is actually recommended (e.g. types of public members).

2 Likes