Hacker News Reader

Comment by matsemann | Hacker News Reader

The stdlib of kotlin with immutable types, lots of good extension functions on for instance lists etc is hard to beat. Especially with the nice lambda syntax it makes it a joy to write functional code compared to streams and having to call separate functions by wrapping instead of chaining.

Operator overloading can be misused, but for certain things it makes stuff much prettier as well.

View on HN

Scala stdlib is considerably better than the one from Kotlin, one detail I dislike about Kotlin collections is that `map` invocations always result in a List.

Kotlin's standard collection are "immutable collections" only in the sense that they are read-only. Adding an element to a Kotlin immutable set copies the whole thing,

https://github.com/JetBrains/kotlin/blob/924c28507067cbfbf78...

This is not that different from Java unmodifiable. In contrast the Scala immutable Set supports constant time addition,

https://docs.scala-lang.org/overviews/collections-2.13/perfo...

This isn't just an ivory tower concern either. Because Kotlin immutables aren't actually immutable (they just don't expose mutation interfaces) this means that if I get a ref to an immutable Set, I can't modify it but I can't rely on it not changing because it's still back by a mutable one.

Did kotlin ever add an equivalent of parallel streams?

Yes, via co-routines and flows. And with some convenient extension functions you can easily deal with Java APIs that take or return streams. The structured concurrency proposal in JDK 21 takes some steps in the same direction. That's basically the higher level stuff that will make Loom more usable.

In general the theme of that release seems to cherry pick a lot of stuff that Kotlin and Scala have been supporting for some time. That's a good thing. Java developers have been missing out on a lot of good stuff. There's quite a bit more of that of course where this came from.

Reply on news.ycombinator.com