kotlinx.collections.immutable VS MapDB

In Clojure, it is called an Atom. I created my own via AtomicReference and https://github.com/Kotlin/kotlinx.collections.immutable. It works really well in Kotlin. It works especially well if you use tons of coroutines.

So does Java! Also, kotlinx.collections is still not stable and I don't think they are intending to make it so any time soon.

If you want to have O(1) with prepend you use the LinkedList. You get a lot of functional benefits but also all of the downsides like no random access. You can use the https://github.com/Kotlin/kotlinx.collections.immutable library to get O(log_64(n)). I haven't spent a ton of time on Tries so I might be a little wrong on that bound. BTW, these are persistent immutable data structures. At work, we use them inside of AtomicReference to roll our own Clojure Atoms.

This is why Kotlin refers to List as read-only, and not immutable, and has created a library for truly immutable collections: https://github.com/Kotlin/kotlinx.collections.immutable

What I know is only based on this discussion. It seems that pcollections is really outdated and should not be considered.

If you want true immutable collections, kotlinx.collections.immutable provides them. They will likely be integrated into the language eventually with value classes and better immutability support.

I could see this argument made with Clojure, but I don't really see what makes Scala significantly better at FP than Kotlin. Kotlin has an official persistent data structures library nowadays, and it's got lambdas and higher order functions.

It's not immutable, it's read-only, https://kotlinlang.org/docs/reference/collections-overview.html . I think that's a false assumption. But I get the point - immutable collections are not part of the std - for very good reasons. But we know each other, I assume that you will disagree :) For people who know what they want and know all the implications, there is https://github.com/Kotlin/kotlinx.collections.immutable .

I decided to start with an overview of what open-source options are currently available. When it comes to the implementation of the on-heap cache mechanism, the options are numerous – there is well known: guava, ehcache, caffeine and many other solutions. However, when I began researching cache mechanisms offering the possibility of storing data outside GC control, I found out that there are very few solutions left. Out of the popular ones, only Terracotta is supported. It seems that this is a very niche solution and we do not have many options to choose from. In terms of less-known projects, I came across Chronicle-Map, MapDB and OHC. I chose the last one because it was created as part of the Cassandra project, which I had some experience with and was curious about how this component worked:

So, it's an object database, like Zope's ZODB on Python?

I like the idea, but I'd like to learn about use cases for it.

Otherwise, in Java, MapDB is about as far as I'd be willing to go: https://github.com/jankotek/mapdb/

Anyway, without further ado, I found MapDB (https://github.com/jankotek/mapdb) which does exactly that. Of course, they also provide their own Java collection implementations as well, so I suspect using it with Vavr would be a poor idea, but it is very cool in its own right anyway. Of course, there is also Apache Derby and HSQLDB, and those great options with a long history as well. I haven't played with these in a while though, so I might give them a try again soon for some personal stuff.

In Java I like

https://mapdb.org/

It is more feature rich than you want but in Python I'd probably just use sqlite3 since it is in the standard library.

I have had good results with mapdb