[HN Gopher] Immutable Approaches
       ___________________________________________________________________
        
       Immutable Approaches
        
       Author : Tomte
       Score  : 11 points
       Date   : 2021-03-06 09:00 UTC (2 days ago)
        
 (HTM) web link (macwright.com)
 (TXT) w3m dump (macwright.com)
        
       | pharmakom wrote:
       | The clunkyness of this is what drove me away from JS (among other
       | things). Now I functional compile-to-js languages and it's a joy!
        
         | adamkl wrote:
         | I think it's interesting that libraries like Immutable.js,
         | Immer and Ramda show that there is a real appetite amongst
         | JavaScript developers to embrace a more functional approach,
         | but at the same time languages like ClojureScript, Elm, and
         | Rescript don't see more adoption.
         | 
         | I suppose it's all a trade off. The pain of jumping through
         | hoops with the libraries mentioned above vs dealing with an
         | entirely different language and having to hire/train for it.
        
       | jzoch wrote:
       | This approach is sort of similar to an LSM - you can make this
       | more efficient by doing a routine compaction in your storage
       | whereby you collapse many patches on top of the original version
       | and call it v2. You can say have a row with the same id (manage
       | those conflicts!), a reference to the last patch applied, and a
       | new version number. Then, you just always query the latest
       | "version".
        
         | sbazerque wrote:
         | Depends on whether you've gone crypto or not. If each patch is
         | authored and signed by some form of crypto id in a
         | permissionless p2p system, there's no central authority to
         | create the compact version of the patch.
        
       ___________________________________________________________________
       (page generated 2021-03-08 23:01 UTC)