"A lisp machine with fully automatic persistence. No database or filesystem needed" is actually a fairly accurate description.
11 karma · joined August 9, 2023
"A lisp machine with fully automatic persistence. No database or filesystem needed" is actually a fairly accurate description.
The win is basically that the entire stack gets much less complex. Network, database, and business logic all operate within the same model.
For example, once the system is finished, building a full p2p chat should be possible in a couple hundred LOC.
The goal is somewhat political, to enable people to build their own social software, instead of depending on finance for everything.
> I also don't think I can see such a design ever doing anything very quickly, as every operation is necessarily committed to disk.
There is overhead to be sure, but it's nowhere near as bad as it sounds.
In practice, we don't need to fsync every input. Each syscall chooses if it should wait for a sync before running effect. Sync only blocks that effect, everything else continues to run.
For example most REPL IO doesn't need to wait for a sync, but a network transaction does.
Making processes persistent has nontrivial overhead, so the Erlang model probably doesn't translate well in practice to Plunder.
Plunder is not an obscurantist project, and intends to be straightforward and easy to understand.
Here is a recent attempt to explain the paradigm succinctly: https://git.sr.ht/~plan/plunder/tree/master/item/doc/PLAN.md
Very open to feedback as to how to express these ideas more clearly.
https://git.sr.ht/~plan/plunder/tree/master/item/doc/PLAN.md
This document was written by an Urbit dev, and the Urbit community is the target audience.
The conversation here seems to be mostly shitting on Urbit with the usual HN critiques.
However, Plunder is only tangentially related to Urbit.
It's the same paradigm, but totally different otherwise. Heavy Haskell influence.
The project is still mostly underground, but I'm happy to answer any questions.