[HN Gopher] Immutability Changes Everything (2016) [pdf]
___________________________________________________________________
Immutability Changes Everything (2016) [pdf]
Author : fire_lake
Score : 30 points
Date : 2025-01-25 21:25 UTC (1 hours ago)
(HTM) web link (www.cidrdb.org)
(TXT) w3m dump (www.cidrdb.org)
| dang wrote:
| Related:
|
| _Immutability Changes Everything (2016)_ -
| https://news.ycombinator.com/item?id=27640308 - June 2021 (94
| comments)
|
| _Immutability Changes Everything_ -
| https://news.ycombinator.com/item?id=10953645 - Jan 2016 (4
| comments)
|
| _Immutability Changes Everything [pdf]_ -
| https://news.ycombinator.com/item?id=8955130 - Jan 2015 (25
| comments)
|
| (Reposts are fine after a year or so; links to past threads are
| just to satisfy extra-curious readers)
| lbj wrote:
| I have to say, I really love the title :)
| cacozen wrote:
| I guess "Immutability changes nothing" wouldn't have the same
| impact
| gleenn wrote:
| I love the quote "accountants don't use erasers". So many things
| should be modeled over time and keep track of change right out
| the gate. Little things like Ruby on Rails always adding
| timestamps to model tables was super helpful but also a little
| code smell. If this is obvious enough to be useful everywhere,
| what is the next level? One more reason Datamoic is so cool:
| nothing is overwritten, it is overlayed with a newer record and
| you can always look back and you can always also always take a
| slice of the db at a specific time and have a complete and
| consistent viewbof the universe at that time. Immutability!
| LeftHandPath wrote:
| Immutability is a fantastic tool, especially when working with
| enterprise data. It's relatively easy to implement your own
| temporal tables on most existing databases, no special libraries
| or tools required. It seems really trivial/obvious, but I'll
| admit I first stumbled into the concept using the AS400 at work.
| If you make a mistake on payroll in IBM's old MAPICS program, you
| don't overwrite or delete it. You introduce a new "backout
| record" to nullify it, then (maybe) insert another record with
| the correct data. It seems obvious once you've seen the pattern.
|
| I've made a few non-technical eyes go wide by explaining A) that
| this is done and B) how it is done. The non-tech
| crypto/blockchain enthusiasts I've met get really excited when
| they learn you can make a set of data immutable _without_
| blockchain / merkle trees. Actually, explaining that is a good
| way to introduce the concept of a merkle tree / distributed
| ledger, and why "blockchain" is specifically for systems without
| a central authority.
|
| (Bi)Temporal and immutable tables are especially useful for
| things like HR, PTO, employee clock activity, etc. Helps keep
| things auditable and correct.
| prydt wrote:
| One of my favorite papers! This reminds me of Martin Kleppmann's
| work on Apache Samza and the idea of "turning the database inside
| out" by hosting the write-ahead log on something like Kafka and
| then having many different materialized views consume that log.
|
| Seems like a very powerful architecture that is both simple and
| decouples many concerns.
___________________________________________________________________
(page generated 2025-01-25 23:00 UTC)