I'm curious, are people in this slack interested/i...

# arrow

[Nir]

I'm curious, are people in this slack interested/involved at all with kotlinx.immutable?

[raulraja]

not that I’m aware of, but as soon as it gets out of being experimental our plan was to add the proper arrow support for it in a separate module to not depend on it from core. Arrow core/fx/continuations should follow the std lib and no other deps so it can serve as foundation block for building other libraries and infra in heterogeneous places.

[Nir]

It seems to me like a huge waste that the standard library is filled with functions that return List, Map, etc, that they have constructed themselves

[Nir]

if you call .map { it }, you get a list that nobody else has a reference to, and you only have a read-only reference to it. So, it's immutable shy of deliberate down casting, which is horrible code smell anyway.

[Nir]

I feel like all these functions should be returning ImmutableMap, ImmutableList, etc instead

[raulraja]

There are reasons related to java compatibility, size, etc here that can’t be really discarded IMO. Bundling persistent collections in the std lib would considerably increase its size among others. It also does not help with the case that most interop Java code uses mutable collections which is very important to Kotlin as a lang.

[Nir]

you mean, like passing the result of map back into Java code?

[raulraja]

I mean that If the std lib bundled persistent collections it would be much larger as in Scala 2. Which is not great for adoption and increases the maintenance burden provided they don't need to maintain the data structures themselves today. Also for Java interop is not really clear if in a use case you'd have to be converting existing mutable collections coming from Java to immutable ones. That has a cost in memory and computation and you are turning that into a common case now with conversions layers between collection types as it also happens in Scala.
Most Java callers would want to work with the Java collection types when interacting with Kotlin code which are the mutable ones to avoid wrapping and shuffling just to go from mutable to immutable.

So my opinion is while this is not the ideal FP encoding it's worth it because they got more traction and still have the chance to introduce persistent collections as library.

[Nir]

IMHO, it's annoying, but it would be nice if kotlinx.immutable provided versions of all the map etc functions that returned ImmutableList

[Nir]

opt-in

[Nir]

it could even use an ImmutableList implementation that's just a wrapper around a List to ensure that mutation does not actually occur

[raulraja]

Yeah I think that suggestion may be accepted or discussed. Maybe worth an issue