8sync 0.2 released, and the future of 8sync -- 8sync

Hello one and all! I'm pleased to announce 8sync 0.2, the thrilling second release of 8sync. What's in store? Well...

Actors, enter stage left!

This release brings an entirely new (and entirely optional) actor model subsystem built on top of 8sync's existing concurrency facilities and GOOPS, and inspired by prior experience designing XUDD. In short, the actor model is a "shared nothing" environment where actors only hold addresses, not direct references, of each other, and where the only communication between actors is through message passing. Actors consume messages from their inbox and propagate messages throughout the actor graph. Callback hell is avoided in a way similar to 8sync core; actors can send messages but "wait" on replies, suspending their procedures mid-execution until a response comes.

Perhaps a demonstration is in order. Some of you may recognize this actor subsystem from the blogpost about Mudsync and the Lisp Game Jam. Yup, this is pretty much exactly the same software as used there! In the blogpost we gave an example of ringing a bell. Let's take a look at the very code for the summoning bell, mentioned previously! (Or more specifically, its action handler for being rung.)

(define-mhandler (summoning-bell-cmd-ring bell message) ;; Call back to actor who invoked this message handler ;; and find out their name. We'll call *their* get-name message ;; handler... meanwhile, this procedure suspends until we get ;; their response. (define who-rang (message-ref (<-wait bell (message-from message) 'get-name) 'val)) ;; Now we'll invoke the "tell" message handler on the player ;; who rang us, displaying this text on their screen. ;; This one just uses <- instead of <-wait, since we don't ;; care when it's delivered; we're not following up on it. (<- bell (message-from message) 'tell #:text "*ring ring!* You ring the bell!\n") ;; We also want everyone else in the room to "hear" the bell, ;; but they get a different message since they aren't the ones ;; ringing it. Notice here's where we make use of the invoker's ;; name as extracted and assigned to the who-rang variable. ;; Notice how we send this message to our "location", which ;; forwards it to the rest of the occupants in the room. (<- bell (gameobj-loc bell) 'tell-room #:text (format #f "*ring ring!* ~a rings the bell!\n" who-rang) #:exclude (message-from message)) ;; Now we perform the primary task of the bell, which is to summon ;; the "clerk" character to the room. (This is configurable, ;; so we dynamically look up their address.) (<- bell (dyn-ref bell (slot-ref bell 'summons)) 'be-summoned #:who-summoned (message-from message)))

Pretty cool, huh? I hope that's pretty clear / self explanatory!

Anyway, so the actor model system is pretty cool and fun to use. Unfortunately like (heh) all of 8sync, it's very underdocumented at present. Documentation is of course coming, but I figured that rather than sit on 8sync's current code, I should make a release, especially before big changes happen. And big changes are likely to happen soon!

The exciting, evolving world of Guile async tooling

Just a year and a couple of months ago, things were pretty different when it came to Guile's asynchronous programming story. A few of us sat down, fresh on the doorstep of the FSF 30th party, and discussed what things could be like. Shortly thereafter, I started hacking on 8sync as an experiment in trying to flesh out what kind of asynchronous environment I really wanted... in fact, 8sync's first commit is just a couple weeks over a year old. Happy birthday! Soon after that I gave a talk at FOSDEM about "Paving a Path to Greater Network Freedom" at the Guile Developer Room. (I also gave a talk immediately after called "The Community Guile Could Have" which I think ties in a lot as well, but perhaps more in terms of the necessary social steps necessary for Guile's success, networking-wise and other-wise.)

From here, I think a lot of things took off. Guile's asynchronous programming story is starting to really develop a lot; alongside 8sync, a few asynchronous network programming libraries popped up and started to move along. Chris Vine started guile-a-sync and Andy Wingo started Fibers. And then the real bombshell, I think, is the work Andy Wingo has been doing on revamping Guile's networking tooling, especially the super exciting suspendable ports tooling coming in Guile 2.2. With all this work, I think we're on track for Guile to be one of the most interesting and most satisfying places to do network hacking. What a great time to be alive and be a part of the Guile community! I'd like to think that some of my advocacy, and starting 8sync, helped spur some of this along, but maybe the rest of it would have happened anyway... who knows!

Well regardless of 8sync's role in spurring the rest of this stuff forward, there's another side to it: what does it mean for 8sync? The answer is: I'm not totally sure, but there will be changes. One thing that is clear is that 8sync will move to use the suspendable ports tooling in Guile 2.2; that feature is just too good to pass up and could considerably simplify much of the tooling in 8sync.

But what about 8sync in relation to these other libraries? Again here, I'm not totally sure. I need to explore more of what's happening outside of 8sync's walls. In particular, there's clearly great stuff happening in Fibers, and I'd like to understand that better. I think that Andy Wingo probably has a better grounding in fundamentals and theory than I do. I recommend reading Andy's excellent blogpost (it's also part of the Fibers documentation) explaining thinking about what concurrency facilities are and aren't desirable. With all that hard thinking and work, is it possible that 8sync's event loop could be built on top of Fibers (or guile-a-sync for that matter)? Maybe, maybe! I think I need to play with it and know. Maybe there are reasons to keep experimenting in a separate direction, or maybe we can join forces fairly easily. Time will probably soon tell. "Worst comes to worst" (or is it "worst comes to best"?) it could be that 8sync just becomes an actor model library living on top of one of these other libraries. Which would be a pretty good worst/best case!

No matter what happens, as I said, it's a great time to be exploring network programming in Guile. And of course, you're always welcome to join us in 8sync land!

Onward and upward... have fun hacking in Guile!