Why not acid-state? - Haskell

Welcome to the Functional Programming Zulip Chat Archive. You can join the chat here.

Sridhar Ratnakumar

Are there any arguments against using acid-state? (No simultaneous writes; just one process will write to it).

Sridhar Ratnakumar

From fp slack,

There was some discussion a couple of years ago here: https://gist.github.com/parsonsmatt/6b747d3020c4a4ac43b6580b65392a23

Sridhar Ratnakumar

My response follows:

I just read the gist. My use case is different: using acid-state as a cache store, and as a way to pass on this cache to external processes (written in Haskell, if I have to) without having them rebuild it themselves. It sounds like for this use case, acid-state would be fine - as I get the benefits of using Haskell datatypes (keeping all of it in memory is not a problem).
But compared to something like serializing to JSON, acid-state would only be useful if the reader processes have the capability to 'update' their in-memory copy using incoming patches (from writer process).

(What's this cache? Well, think of a big graph and note metadata built out of a directory of Markdown files)

Mats Rauhala

Acid-state used to be the #1 source of bugs on our codebase.

Mats Rauhala

Causing crashes, data corruption and stackless errors

Georgi Lyubenov // googleson78

in what scenarios do those happen? not finding issues relating to them

Mats Rauhala

Well, tbh we were misusing acid-state a bit. We had an agent service, managing n services, each service having their own acid-state. These environments could come and go dynamically and this coming and going caused problems.

Some of the errors were like

could not open file

which is absolutely useless in trying to debug what, where and how the problem comes to being. No file name, no stack, no anything.

There was also some other syscall that occasionally failed, but that I was able to figure out by git cloning every single transitive dependency and grepping the call from them.