We are glad to announce the first preview version 0.1 of kotlinx.collections.immutable library has been published to bintray.
This library contains interfaces of immutable persistent collections and their implementations. The implementation is based on pcollections. The maturity of this library is far from release, i.e. the implementations are not as optimal as they can be, and the API is subject to change in the future. However they convey our vision of immutable persistent collections and they are ready to try out.
The goal of this release is to provide some bits you can grab and plug into your project easily to play and experiment with. You can find the instructions how to setup the dependency in the README.
We are looking forward to your feedback.
Feel free to submit issues to github, ask questions here or in slack.
I am wondering what are the plans along evaluating improvements suggested by various people in this issue? Is choosing pcollections library as a base a final decision?
No, it’s just something that was very easy to build the prototype from.
We’re definitely to address the performance considerations, but this release is mainly focused on the API.
Couldn’t most (if not all) of these improvements be integrated into the operator functions on Kotlin’s existing read-only collections? A big selling point of Kotlin for me is its terse and minimal runtime, and the practice of adding more and more collections for fear of changing implementations underneath interfaces is how Java got to be such a mess in the first place.
@jonlatane Do you mean we should change the List<T> implementation returned from listOf or map from ArrayList to some ImmutableList?
This definitely will have implications on the performance, and I’m afraid not for the better one.
Why would it be slower? Typically immutable collections can be implemented with a higher performance than mutable collections because at least you don’t need safeguards against concurrent mutation operations and you can omit defensive copying in a lot of cases.
I would guess it does depend on the use, but don’t count out the JVM. If the list is effectively immutable the JVM can observe that and omit the copying as well. The problem with immutable collections is that any modification is either a copy or a more complicated structure with (possibly) additional costs.
I’d recommend building on Vavr (formerly called Javaslang) rather than pcollections. Of note, they use a high-performance red-black tree for the guts of their functional tree-based maps and sets and a hash array mapped trie for hash-based maps and sets. You could do a lot worse than to start from here if you want speed.
Also of note, Vavr went to a lot of trouble to come up with its sequence abstraction and value abstraction which lets Option, Try, and other things all share code under the hood. It would be really neat if Kotlin offered similar features.
Not a fan of pcollections either. Hell, I would probably be most happy with simple collection classes like in Google Guava. They’re very efficient and have simple code that’s easy to prove to be correct. The persistence stuff again creates pitfalls and large amounts of code and so on and I would rather like to keep that out of a core library.