If you look through the search engine code, you might notice it’s organized differently than the typical microservice-based backend. We have functions we’ve written, and we have nodes, but we don’t have (micro)services per se. There’s actually a shift in perspective here that I think is important, and it’s somewhat subtle.
There are huge benefits to modeling the codebase as an immutable data structure, rather than a bag of text files that’s mutated in place. This post talks about these benefits while walking through a design for how such a codebase can be edited using ordinary tools—your favorite text editor, Git, and a simple command line tool that I’ll introduce here. The approach described is simple, easily implementable, and will let us test out the ‘user experience’ of Unison’s immutable codebase and refactoring story. Though I’ll be showing how things work with a hypothetical command-line tool, it should be pretty clear how the same workflow could be quite nicely exposed in a richer semantic editor.
More progress. Right now we have a really minimal persistent data API which provides just a single type, a key-value store, called
Index k v:
As of this PR, we got our first distributed program to run successfully. The program dynamically spawns two Unison nodes and ping-pongs a number back and forth between them until the count reaches 5. This exercises a huge amount of code - the
BlockStore implementation that Sam has worked on, Arya’s parsing code, the node container code I wrote which handles spawning of new local nodes, the distributed programming API implementation, which is responsible for automatically transporting the computation back and forth between the nodes, and lots more:
Exciting news! There’s now a Zazzle store where you can purchase way overpriced t-shirts, stickers, and other swag as a way to support the project and REPRESENT!! Like the Patreon campaign, all income from the store (after Zazzle takes their cut) will go toward supporting the open-source project.