4 ms·

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

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.

AlexITC 3y ago
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.
jbellis 3y ago
Did kotlin ever add an equivalent of parallel streams?
- jillesvangurp 3y ago
  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.
xmcqdpt2 3y ago
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/924c28507067cbfbf78a6509ea89eabe496e34ca/libraries/stdlib/common/src/generated/_Sets.kt#L84 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/performance-characteristics.html 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.

AlexITC 3y ago

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.

jbellis 3y ago

Did kotlin ever add an equivalent of parallel streams?

jillesvangurp 3y ago
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.

xmcqdpt2 3y ago

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/924c28507067cbfbf78a6509ea89eabe496e34ca/libraries/stdlib/common/src/generated/_Sets.kt#L84 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/performance-characteristics.html 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.