Immer – A library of persistent and immutable data structures written in C++ | Hacker News Reader

Immer – A library of persistent and immutable data structures written in C++

github.com

127 pointssmartmic18 comments

Any sense how, if at all, C++ Immer and JS Immer relate as projects? They’re basically meant to be the same thing but I haven’t found either acknowledging the other.

Completely unrelated.

- Immer (C++) appears to be roughly equivalent to Immutable.js ( https://immutable-js.com/ ): a set of specialized data structures

- Immer (JS), on the other hand, uses JS Proxies to wrap plain values, traps attempted mutations, and then replays them to return a safely immutable updated final result

As far as I know, Michel Weststrate came up with the name independently (although I can't 100% confirm that).

(source: I didn't create Immer (JS), but I started using it in Redux Toolkit in 2018, am quoted in the docs about how much I love it, spent the last couple months doing performance optimization work that got shipped in Immer 11.x, and just put up some more bugfix PRs today. I'm a secondary maintainer at this point.)

Thanks for your work, really appreciated the RTK perf boost!

'Immer' is just German for 'always' or 'eternal'. So giving that name to your library of persistent and immutable data structures is a fairly natural thing to do, without them having anything more in common than that.

(Of course, they might have more in common, I don't know.)

Immer is also a dutch word, with the same meaning as in german.

I would never translate “eternal” to “immer”, but rather “ewig”. “Always” is the corrent translation, imo.

Sure, though 'never' is a bit of a strong statement. It depends on context and what's idiomatic.

An example:

DE: Er schwor, ihr auf immer treu zu sein.

EN: He swore to be eternally faithful to her.

True, that works, but I still think “Er schwor, ihr ewig treu zu sein.” is the more natural translation.

Popular in:

2019 (102 points, 56 comments) https://news.ycombinator.com/item?id=20947222

2016 (144 points, 46 comments) https://news.ycombinator.com/item?id=13049843

For the curious, yes they provide a garbage-collected heap [1] as well as reference counting.

[1] https://sinusoid.es/immer/memory.html#classimmer_1_1gc__heap

Cool! I just implemented RBB trees for c#. Not on this level, mostly just for fun. I am not a programmer at all, but I do like myself a neat data structure.

I am currently fighting the JIT to understand why a simple flags check (ANDing two bytes and comparing to 0) makes the code 2.5x slower. This is my first c# project so right now I am just throwing things at the compilrr to see what sticks. If anyone knows where I can get help, that would be much appreciated. Dont look too closely on the benchmarks. I managed to make two of them an absolutely best case for ImmutableList (especially SetItem which should degrage linearly with size but now is O(1))

https://github.com/bjoli/RrbList/tree/main/src/Collections

Another thing I havent figured out is how to setup docfx to just pull my XML comments and generate API documentation.

I used this library extensively in a prototype of a project and it was awesome!

Besides performance, the API is very well thought.

This library always makes me feel small - as in, I wish I did the cool things which call for such solutions. :)

I just tried building some immutable data structures in Go: (https://github.com/dacapoday/smol) a kv store base on cow b+ tree

In-memory immuatable data structures seem to be only suitable for scenarios with large amounts of data and high concurrency. In most scenarios, this actually incurs a lot of additional copying overhead.

Anyone else religiously went through 490 packages in cppget to make sure they aren't missing out?

Good stuff. Very good stuff.

Really cool!

Reply on news.ycombinator.com