TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Immutability Changes Everything (2016) [pdf]

118 pointsby fire_lake4 months ago

10 comments

LeftHandPath4 months ago
Immutability is a fantastic tool, especially when working with enterprise data. It&#x27;s relatively easy to implement your own temporal tables on most existing databases, no special libraries or tools required. It seems really trivial&#x2F;obvious, but I&#x27;ll admit I first stumbled into the concept using the AS400 at work. If you make a mistake on payroll in IBM&#x27;s old MAPICS program, you don&#x27;t overwrite or delete it. You introduce a new &quot;backout record&quot; to nullify it, then (maybe) insert another record with the correct data. It seems obvious once you&#x27;ve seen the pattern.<p>I&#x27;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&#x2F;blockchain enthusiasts I&#x27;ve met get really excited when they learn you can make a set of data immutable <i>without</i> blockchain &#x2F; merkle trees. Actually, explaining that is a good way to introduce the concept of a merkle tree &#x2F; distributed ledger, and why &quot;blockchain&quot; is specifically for systems without a central authority.<p>(Bi)Temporal and immutable tables are especially useful for things like HR, PTO, employee clock activity, etc. Helps keep things auditable and correct.
评论 #42826553 未加载
评论 #42825950 未加载
评论 #42827000 未加载
评论 #42827915 未加载
gatane4 months ago
My main gripe with immutability is that making updated data requires building a full copy of the data again with the changes. Sure, you could have zippers to aid in the updating process by acting as a kind of cursor&#x2F;pointer, but raw access to data beats them anytime (even if you optimize for cache).<p>So if you had to optimize for raw speed, why not choose mutable data?<p><a href="https:&#x2F;&#x2F;ksvi.mff.cuni.cz&#x2F;~sefl&#x2F;papers&#x2F;zippers.pdf" rel="nofollow">https:&#x2F;&#x2F;ksvi.mff.cuni.cz&#x2F;~sefl&#x2F;papers&#x2F;zippers.pdf</a>
评论 #42827028 未加载
评论 #42829189 未加载
评论 #42827197 未加载
评论 #42828649 未加载
评论 #42827503 未加载
dang4 months ago
Related:<p><i>Immutability Changes Everything (2016)</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27640308">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27640308</a> - June 2021 (94 comments)<p><i>Immutability Changes Everything</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10953645">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10953645</a> - Jan 2016 (4 comments)<p><i>Immutability Changes Everything [pdf]</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8955130">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8955130</a> - Jan 2015 (25 comments)<p>(Reposts are fine after a year or so; links to past threads are just to satisfy extra-curious readers)
gleenn4 months ago
I love the quote &quot;accountants don&#x27;t use erasers&quot;. 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!
评论 #42846164 未加载
cowsandmilk4 months ago
The “right to be forgotten” has caused a lot of conflicts with certain immutable data stores. If I can reconstruct a snapshot with a user’s data, have I actually “forgotten” them? Having a deadline where the merges fully occur and old data is rendered inaccessible is sometimes necessary legally.
评论 #42831619 未加载
评论 #42832596 未加载
prydt4 months ago
One of my favorite papers! This reminds me of Martin Kleppmann&#x27;s work on Apache Samza and the idea of &quot;turning the database inside out&quot; by hosting the write-ahead log on something like Kafka and then having many different materialized views consume that log.<p>Seems like a very powerful architecture that is both simple and decouples many concerns.
评论 #42829878 未加载
lbj4 months ago
I have to say, I really love the title :)
评论 #42825518 未加载
skybrian4 months ago
Editors and form validation are where this gets tricky. The user isn&#x27;t just reporting new, independent observations to append to a log. They&#x27;re looking at existing state and deciding how to react to it. Sometimes avoiding constraint violations with other state that they&#x27;re <i>not</i> looking at is also important.<p>It often works out, but if you&#x27;re not looking at the right version then you&#x27;re risking a merge conflict.
niuzeta4 months ago
Semi-related, but is there any repository(ies?) that comprise of these technical white papers? I&#x27;m fascinated by these papers whenever they show up in my feed and I gorge on them, and I&#x27;d love more. I can&#x27;t be the only one thinking this way.
评论 #42828926 未加载
sstanfie4 months ago
Needs more exclaimation points!