Here’s a quick summary of recent updates:
I’ve been pretty absorbed with client work the past couple weeks and don’t have too much to share regarding Unison. And I’ll be away on vacation next week. I’ll plan on doing a post two weeks from today and should have more to share then. Here’s what I do have right now:
Quick update: The design work I’ve been absorbed with the past few weeks feels like it’s at a pretty good stopping point for now. Working through the well-typed editing story was really satisfying since that has felt like a big unknown for the project.
This post describes a design for how to make large-scale edits to a Unison codebase, while ensuring these edits produce code that is well-typed. The approach I’ll describe here is simple, implementable, and has some nice properties:
This post describes the design of an API for distributed evaluation of Unison programs, and for describing, deploying, and executing distributed systems written in Unison. The API I’ll propose here is simple, powerful, and quite easy to implement given the assumptions made by Unison. (I would not be surprised if an initial implementation took less than a week.) In this API, we get to simply declare that a computation be evaluated at a remote node. That computation can be any expression whatsoever in the Unison language, and any needed dependencies of that expression not already known to the remote node will be synced automatically. And this sort of transport never requires any boilerplate plumbing code, manual parsing or serialization (though we can if we wish override wire formats easily). Sounds awesome, right?