I’d like to get a first release of Unison out by end of 2017 or sooner. The release won’t be a toy or proof-of-concept; provided you don’t mind being on the bleeding edge of a new language, this first release should be usable for real work. The big things missing before that can happen are:
At Full Stack Fest, I gave a talk on how to use Unison’s distributed programming API to write a simple search engine that runs on multiple nodes:
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: