https://www.gdcvault.com/play/1012210/The-Implementation-of-...
Spritely Goblins v0.11.0, time travel distributed debugger and more - https://news.ycombinator.com/item?id=35864365 - May 2023 (1 comment)
Growing a Networked Garden with Spritely Goblins - https://news.ycombinator.com/item?id=34031136 - Dec 2022 (2 comments)
Maybe we should convert this thread to a discussion of the project as a whole, rather than of a point release?
I am surprised you didn't find more discussion, though. I'm pretty sure I first heard of the project and have seen it here multiple times. I think it's more often (or in the past) just "Spritely". If your search included the word "Goblins" instead of just "Spritely", that might have narrowed it down excessively.
What if an interpreter wrote every event down to a variable change to a database-like WAL, making it resumable after a crash? Downside: it would be slow, and there would need to be provision for transaction boundaries and for access to network sockets and other non-serializable resources. Upside: develop incrementally in the Smalltalk REPL style, never worry about the data layer at all, backup or give developers a copy of the whole application state - for utilities or LOB apps of limited scope or complexity, why not?
There's this wonderful paper from Usenix OSDI 2014 [1] in which the authors present an eidetic system: "a computer system [should] provide the ability to recall any past state that existed on the computer, and further, [should] be able to provide the lineage of any byte in a current or past state."
They implemented and evaluated it, too: "Preliminary data from several weeks of continuous use [show that] storage requirements for 4 or more years of usage can be satisfied by adding a 4 TB hard drive to the system. Further, the performance overhead on almost all workloads we measured was under 8%."
[1]: Devecsery, David, MIchael Chow, Xianzheng Dou, Jason Flinn, and Peter M. Chen. “Eidetic Systems.” In Proc. 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14), 2014. https://www.usenix.org/conference/osdi14/technical-sessions/...
I built a workflow engine in the past on the JVM that uses serializable continuations, a bit like what Goblins is doing. The important part is not the VM-level engineering, the important part is defining the boundaries of what gets serialized. If you actually checkpoint everything then you can't upgrade your software anymore, because developers think about program upgrades as reloading from a blank slate, not hot-patching a running program in memory. OK maybe some Lisp devs think in the latter way, but most people don't, and the moment you upgrade a library from one version to another of course there is no instructions for how to incrementally patch your way in memory from one to another.
It's also not clear why you'd want to. A lot of program state is plumbing. Logging frameworks, HTTP stacks, thread pools, system configuration, JIT compiler state, etc. There's no point in saving that to disk. It belongs in transient RAM naturally.
It's common to do something similar by writing most of an application as functions over a database and static files, and using scaffolding tools to reinitialise the database when things break.
This happens constantly with software demos. It shouldn't. It's such a silly thing to mess up and takes more effort than just not including a screencapture whatsoever.
Granted, I've played the space shooter in question before, so I do have some context :)
Working out that that's all that's happening (not to mentioning ask the inevitable, "Why is there a screencapture included here at all?") takes about 2–10x the amount of time it takes to read this description that says that's what it's showing.
