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.<p>- Immer (C++) appears to be roughly equivalent to Immutable.js ( <a href="https://immutable-js.com/" rel="nofollow">https://immutable-js.com/</a> ): a set of specialized data structures<p>- 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<p>As far as I know, Michel Weststrate came up with the name independently (although I can't 100% confirm that).<p>(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.)
'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.<p>(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.<p>An example:<p>DE: Er schwor, ihr auf immer treu zu sein.<p>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:<p>2019 (102 points, 56 comments) <a href="https://news.ycombinator.com/item?id=20947222">https://news.ycombinator.com/item?id=20947222</a><p>2016 (144 points, 46 comments) <a href="https://news.ycombinator.com/item?id=13049843">https://news.ycombinator.com/item?id=13049843</a>
For the curious, yes they provide a garbage-collected heap [1] as well as reference counting.<p>[1] <a href="https://sinusoid.es/immer/memory.html#classimmer_1_1gc__heap" rel="nofollow">https://sinusoid.es/immer/memory.html#classimmer_1_1gc__heap</a>
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.<p>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))<p><a href="https://github.com/bjoli/RrbList/tree/main/src/Collections" rel="nofollow">https://github.com/bjoli/RrbList/tree/main/src/Collections</a><p>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!<p>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:
(<a href="https://github.com/dacapoday/smol" rel="nofollow">https://github.com/dacapoday/smol</a>)
a kv store base on cow b+ tree
Anyone else religiously went through 490 packages in cppget to make sure they aren't missing out?
Good stuff. Very good stuff.
Really cool!