In Unison, arbitrary values in the language may be serialized and persisted and/or transported to other Unison nodes, without fear of conflicts or dependency hell. This does raise an important question: how do we deal with Unison nodes with different local capabilities? For instance, a node might have access to a local database or its own local file system, or a legacy shared library. Or we might want to create an IoT application in which Unison is being used to abstract over a heterogeneous collection of appliances with different sensors.
I decided to do a head-to-head speed test comparing the current Unison editor to raw text editing in Vim. Below, here’s me writing the same code in the Unison editor and in Vim, typing at similar speeds, strictly using the keyboard with both:
I did a major overhaul of the About page. Rather than try to describe everything about the project in full generality (which wasn’t working very well IMO), the new page now starts with a very concrete overview of the editor and then uses that to introduce some of the other ideas of the project. I think this works better for people who come to this site and wonder what the heck is going on here?
Exciting news everyone! I am going to be starting a company based around Unison. What form that company takes is still somewhat TBD, but the idea is to have a sustainable business that can fund at least a core group of developers to further build out and improve upon Unison. If you’re reading this and are interested in partnering up to help build something revolutionary, check out the official job posting at unisonweb.org/jobs.
Haven’t posted in a while. I’ve been working on squashing bugs in the editor and trying to get it to a less embarassing state before posting it online for folks to try. (Though the brave can try it now just by building the project yourself! See the GitHub page for instructions.)