next-generation programming language, currently in development

Twitter . GitHub . RSS

Node containers and lightweight, zero-copy node provisioning

We are working on the distributed programming API implementation. After finishing the guts of it, some questions lingered about how to tie everything together. I went off and did some pondering, and now several things are more clear. I’m not sure how much sense this post will make to other people but wanted to do some kind of writeup.

full post

The trouble with adoption of standards


full post

Shared node storage and more efficient distributed execution

First, a quick update: I’m back from paternity leave and I also just wrapped up some client work so I’ll be focused on unison for at least the next several months. I’m super excited to make faster progress now that I can really devote my full attention to it!

full post

Unison as a substrate for the IoT, heterogeneous computing networks, interacting with foreign / legacy code, and social apps

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.

full post

Semantic editing makes programming faster and easier than text editing

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:

full post