What I miss in Java, the perspective of a Kotlin developer(blog.frankel.ch)
blog.frankel.ch
What I miss in Java, the perspective of a Kotlin developer
https://blog.frankel.ch/miss-in-java-kotlin-developer/
2 comments
I tried so hard to get "into" kotlin when I had to use it at a job. It's just kinda boring. Maybe that's a good thing, though.
These are pretty weak arguments
For the first point - val/var
"More importantly, it doesn’t offer its immutable counterpart, val. You still need to add the final keyword, which nearly nobody uses."
This super undermines the criticism. "It has the feature but people don't use it" isn't exactly much to write home about. Just use `final var` if you want. Make "final var over var" the same force culturally as JS's const over let"
"However, the developers of Optional designed it for return values only. Nothing is available in the language syntax for methods parameters and return values. To cope with this, a bunch of libraries provides compile-time annotations:"
This flow of causality here is slightly incoherent. The phrasing implies that if there was a version of optional that was designed for method parameters that would be better and there would be less of a need for compile-time annotations. Here it is
https://www.youtube.com/watch?v=Ej0sss6cq14
It is true though that Kotlin has a more consistent story here, but there are active efforts to improve it for Java.
Also, the discussion of extension functions points out that static methods cannot be chained like instance methods - correct - but doesn't really discuss the other end of the tradeoff. That is that there need to be rules for whether an extension function is "in scope" which can make local analysis for humans harder.
There are also other pretty trivial options for doing static method chaining if that is what you want stylistically.
For the first point - val/var
"More importantly, it doesn’t offer its immutable counterpart, val. You still need to add the final keyword, which nearly nobody uses."
This super undermines the criticism. "It has the feature but people don't use it" isn't exactly much to write home about. Just use `final var` if you want. Make "final var over var" the same force culturally as JS's const over let"
"However, the developers of Optional designed it for return values only. Nothing is available in the language syntax for methods parameters and return values. To cope with this, a bunch of libraries provides compile-time annotations:"
This flow of causality here is slightly incoherent. The phrasing implies that if there was a version of optional that was designed for method parameters that would be better and there would be less of a need for compile-time annotations. Here it is
sealed interface Option<T> {
record Some<T>(T value) implements Option<T> {}
record None<T>() implements Option<T> {}
}
https://www.youtube.com/watch?v=Ej0sss6cq14
It is true though that Kotlin has a more consistent story here, but there are active efforts to improve it for Java.
Also, the discussion of extension functions points out that static methods cannot be chained like instance methods - correct - but doesn't really discuss the other end of the tradeoff. That is that there need to be rules for whether an extension function is "in scope" which can make local analysis for humans harder.
There are also other pretty trivial options for doing static method chaining if that is what you want stylistically.
record Pipeline<T>(T value) {
<R> Pipeline<R> map(Function<? super T, ? extends R> f) {
return new Pipeline(f.apply(value));
}
}
...
final var result = new Pipeline<>("abc")
.map(StringUtils::capitalize)
.map(String::split)
.value();
val result = "abc".capitalize().split();