Spritely Goblins v0.13.0: Object persistence and easier IO

paroneayea | 62 points

Reminded me of a game engine of mine. Years ago I was experimenting with a time travel game concept. It had a virtual machine with green threads whose state could be suspended and serialized into a single binary blob at any time. I basically repurposed the GC's reachability analysis to find all objects reachable from the roots (VM's stack and global variables). IIRC it had also some sort of topological sort when serializing so that most references could be restored in one pass. It also serialized the stack itself and the current instruction pointer. "Manual persistence" they mention is actually quite straightforward to do if you're in full control of the VM. Additionally, it also serialized the physics engine's state as well, so that the forces applied were fully restored (important in a game). The concept was about being able to return to any point in time and have N versions of yourself working together to solve a problem. NPCs and objects had running scripts attached and that's why I needed the whole thing. It also allowed to have proper game saves out of the box. Oh, those were the fun times, and now I'm writing boring enterprise stuff :)

kgeist | 12 days ago

Surprisingly little discussion in the past! But I found these two:

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?

dang | 12 days ago

Why don't we see more general purpose computing environments where the whole interpreter state is persistent and serializable by default? The only ones I'm aware of is R's .RData mechanism, some Smalltalk environments, and solutions at the container/VM level.

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?

waldrews | 12 days ago

This is great! I've been following the Spritely project on the sidelines for a while now and have built a couple toy applications with Goblins; persistence and IO were often my biggest pain points. Looking forward to giving this a try soon!

ryukafalz | 12 days ago

This blog post commits the common sin of showing a screencapture of a terminal emulator session that moves at the speed of thought of the creator rather than presenting things in a reasonable way for the person actually consuming it (i.e. the one in the audience who's trying to work out, without the creator's a priori understanding of what they're doing, the relative significance/insignificance of whatever's flashing on the screen).

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.

cxr | 12 days ago

I know that guile/scheme is uniquely well suited to this, but I'd be interested in hearing why you're using it instead of, say, writing a python library? Is it like a smalltalk thing with really good message-passing, are you getting some guarantees about serializability that are impossible in a more mainstream language? Do you just like it?

traverseda | 11 days ago

How fast is Goblins? I've been considering using it for a project, but I'm worried that it would be too slow. Would it, e.g., be fast enough to serve as a database?

cooljoseph | 12 days ago