It's quite an interesting place to hack on, because it's both a well understood problem but with so many wrinkles to it. I can't count how many earlier designs we chewed through before we ended up with the final one and I would not be surprised if we learn even more about it.

▲

lukebuehler an hour ago | parent | next [-]

Yes, from your release post I can tell that you put a lot of thought into it!

I like your structured concurrency approach with tasks, which is similar to how I do it in Lightspeed too.

Also, the durable state implementation as documents is elegant! Question, though: why directly write/read to the store, why not abstract it and do more of a reducer/redux pattern and hide the persistence of the documents?

	▲	the_mitsuhiko an hour ago \| parent \| next [-]
		> why directly write/read to the store, why not abstract it and do more of a reducer/redux pattern and hide the persistence of the documents? We tried so many things. At one point it pulls in so much more complexity. At one point we had half of automerge's proxy system in there. In the end we felt like this is a reasonable line to draw, but we will see!
	▲	badlogic an hour ago \| parent \| prev [-]
		Things are still not settled, and while the API looks like store i/o it's actually more similar to Immer's drafts, just with a different encoding, as JSON patch can't deal with the kinds of data we encounter in our workloads, at least not in a way that keeps memory and perf within some bounds. The good thing is that this more low level API can be easily papered over with a nice sugary thing.

▲

rcarmo an hour ago | parent | prev [-]

I'm loving it. Already converted a few of my smaller tools to it, and am ripping out the guts of piclaw to replace them (in time)