Goblins: A transactional, distributed actor model environment
docs.racket-lang.org
docs.racket-lang.org
--
It is from the researcher / developer of Goblins himself, Christopher Lemmer Webber. Very interesting indeed.
I know it's not really the point of Racket, but it has all the right attributes^, all it needs is a bigger library ecosystem.
^: including a package manager & build toolchain, an IDE, nicely-formatted web hosting for docs, runtime is reasonably fast, has plenty of batteries included, has cool stuff like contracts, supports multiple programming paradigms.
And it's all the better for it. I wish more sites would follow HN's example.
--
[0] - https://news.ycombinator.com/item?id=16076041
[1] - Mostly, at least - https://news.ycombinator.com/item?id=23374471. It used to be almost for every action, the pg's OG hack, but got optimized away.
[2] - Press CTRL+U.
But here's some more background: I'm co-author/co-editor of the ActivityPub specification, which might give you some idea that I have some experience with trying to build networked systems. Goblins is part of the Spritely project, or even more accurately, the foundation for it: https://spritelyproject.org/
Spritely has some pretty wild ambitions... I won't go into them in detail, the video near the top of the above site explains better. But achieving those in a feasible timeframe means we need some better tooling. Goblins is the foundation of that; it's implemented as a Racket library, but can/will be ported elsewhere. The docs linked above explain some of the core ideas, but honestly I think the video linked from this section of the site explains it better: https://spritelyproject.org/#goblins
In general, people tend to realize that something interesting is happening when they see a cool shiny demo. So here are two pages that might give you an idea with some cool shiny demos:
- Demonstrating "time travel" in a space shooter game (no special code added for this other than exposing it in the GUI): https://dustycloud.org/blog/goblins-time-travel-micropreview... - "goblin-chat", which doesn't look quite as shiny but is interesting more that the code you see above is "end to end encrypted", but is written in a mere 250 lines of code for the whole protocol http://dustycloud.org/blog/spritely-goblins-v0.7-released/
What? How can the last one be only 250 lines of code? (And a mere 300 more for the GUI!) Well, that's because we're implementing a peer-to-peer distributed object programming protocol called CapTP (which includes wild things like distributed garbage collection over the network (for acyclic references), "promise pipelining", and is object capability secure). The next release will be advancing that work significantly. The Agoric organization is also implementing CapTP, but their stuff is in Javascript instead of Racket; we plan to have our CapTPs to converge. Thus it shouldn't really matter whether you write your code in Javascript or Racket, your code should be able to talk to each other.
Anyway, new release coming out soon. Hope that answers some things since the docs page might not convey what's fully interesting about it (and indeed, neither does this text, but the videos mentioned above do a better job).
[1] https://gitlab.com/spritely/ocappub/blob/master/README.org
[2] This talk also has a nice & simple technical perspective: https://www.youtube.com/watch?v=2H-Azm8tM24
Do transactions span distributed actors? Perhaps I missed it, but I see no recovery log.
It implements distributed garbage collection. This is a non-starter for any environment where the network cannot be taken for granted. RMI/DCOM/CORBA had no shortage of problems due to distributed GC alone.
By the way, the "open source version of E" does do distributed garbage collection, but it can't collect cycles across a network barrier. However, the original version of E did collect cycles across the network too: http://erights.org/history/original-e/dgc/
However, you needed hooks into the garbage collector for it to work, since you had to do some introspection of how things were rooted iirc. Mark S. Miller told me that originally they thought this could be fixed because Sun had promised to make Java open source, but they took a damn long time to do it. In the middle period, apparently the E folks said "please! just take this patch... you can have it even!" but Sun didn't merge it.
But Mark also told me that he learned not to push for this, because the cycles-across the network stuff turned out to not be common enough to bother, and you could build distributed acyclic gc using just weakrefs (and weak maps) and gc finalizer hooks, which are much more common than the rooting-introspection stuff.
Not sure if I got all that right, but there you go.
Anyway, I'll fix the tagline for Goblins for next release to make it clearer. Thanks for the feedback.
For more info on "why", see:
https://doc.akka.io/docs/akka/current/typed/guide/actors-int...
https://www.microsoft.com/en-us/research/wp-content/uploads/...
>Use of actors allows us to:
> Enforce encapsulation without resorting to locks.
> Use the model of cooperative entities reacting to signals, changing state, and sending signals to each other to drive the whole application forward.
> Stop worrying about an executing mechanism which is a mismatch to our world view.
Did anyone here use Goblins for any project and would like to share their experience?
So despite it being a solution that has existed for distributed systems since the 70s I was watching a talk from Microsoft on the topic where they would refer to actors as “cloud native objects” and the model itself as an ideal way to do OOP on distributed systems. The marketing feels a little cringe at first but the mental model works well.
I have an object which contains some state. Normally I would be responsible for managing the entire lifecycle of this object including resolving race conditions for DB writes and a million other problems that make distributed systems difficult. With many modern implementations of the actor model however (Microsoft have done a lot of interesting stuff here building Azure and Xbox games like Halo using Actors heavily) you don’t have to worry about any of this. You can just call the object as though you had unlimited RAM and it was in memory for you and race conditions were no longer a thing that you had to worry about.
This paper is a good intro to the topic I found https://www.microsoft.com/en-us/research/wp-content/uploads/...
Was that my Orleans Deep Dive video? https://youtu.be/R0ODfwU6MzQ
I started referring to Grains as Cloud Native Objects as a way to better convey them to people who aren't familiar already. My view is that Grains are different enough from Erlang/Akka style actors that lumping them under the Actor terminology can cause confusion. In the research publications, the term Virtual Actor is coined, which better describes them.
That video doesn't discuss it, but Orleans also supports distributed cross-actor ACID transactions, largely thanks to Phil Bernstein: https://www.microsoft.com/en-us/research/publication/transac... and more recently https://www.microsoft.com/en-us/research/publication/resurre....
The ergonomics of the Haskell implementation could use some work IMO, and I've got some ongoing refactoring work on a branch. But it does work, and folks are using it.
[1]: http://erights.org/