Why so much love for lmdb when so many are past that already?

[sebastienros]

Don't take it too seriously, I am nobody to tell you what to do. But seeing your love for it I am wondering. For instance projects like RocksDb have raised the bar a lot, and recently watched some lectures telling us that MMF is too risky to be worth it.

[CoreyKaylor]

This one for me was more of a love for Kotlin and a familiar API that I think the Kotlin ecosystem could benefit from. I see a lot of Kotlin multi-platform project libraries that suffer from delegating a corresponding platform API that differs greatly from the Kotlin one and it comes at a cost of either the API surface changing negatively in Kotlin, or a performance hit for it being so different. My attempt was to get as close to the native layer as possible but maintaining as much as possible the Kotlin friendly approach.

Regarding RocksDB, I'm sure he has more current thoughts on the matter. But here is a rant from the LMDB author from 9 years ago.

https://www.reddit.com/r/Monero/comments/4rdnrg/lmdb_vs_rocksdb/

[CoreyKaylor]

I mean, look at this elegance. The underlying ability to pass delegates that get inlined allows you to get very clean straightforward code on the Kotlin surface but still scoped safe memory calling into the native lib. 😄

https://github.com/CoreyKaylor/kotlin-lmdb/blob/main/src/commonMain/kotlin/Cursor.kt

https://github.com/CoreyKaylor/kotlin-lmdb/blob/main/src/nativeMain/kotlin/ValN.kt

https://github.com/CoreyKaylor/kotlin-lmdb/blob/main/src/commonMain/kotlin/Env.kt