Haskell, Erlang, and Frank walk into a bar – and begin new project to work in Unison

At the Strange Loop conference in St. Louis, Missouri, earlier this month, Paul Chiusano, founder of Unison Computing, gave the audience a tour of Unison, an emerging programming language designed for building distributed systems.

Created by Chiusano, Arya Irani and Rúnar Bjarnason, Unison was inspired by Haskell, Erlang, and Frank, a trio of functional programming languages. It's an open source statically typed functional programming language and it's currently in public alpha testing.

Chiusano, in his presentation at the conference, said Unison is based on a core technical ideal. "In Unison, we're going to identify definitions not by their name but by a hash of their content," he explained.

Programmers commonly define functions by giving them names like "foo" or "bar." You can do that in Unison too, but the way the language keeps track of those names – which are just metadata in Unison – is by associating them with a 512-bit SHA3 content hash of the implementation of that function.

Using a hash as the address of specific content has implications for the way Unison code gets stored. "For each hash, we're going to store its serialized abstract syntax tree," said Chiusano.

That abstract syntax tree (AST) stores hashes of various dependencies – the basic operations within the definition at issue. And that AST becomes the source of truth for a Unison program, rather than a textual representation stored in files.

Chisano said no one has really tried to build a programming language around this idea, though it appears OCaml stores MD5 hashes of the modules it depends on, to verify them at link time. And hashes are widely used as unique identifiers in a variety of applications.

The Unison website offers an apt metaphor to understand content-based addressing. "Unison definitions are like stars in the sky," the site says. "We can discover the stars in the sky and pick different names for these stars, but the stars exist independently of what we choose to call them."

The idea shares some conceptual similarities to return oriented programming, where program functionality gets assembled by referencing memory addresses to access specific machine instruction sequences.

Making code addressable by hash has significant implications for developers working with Unison.

"We're not going to have builds any more," said Chiusano. "We're going to be able do renames trivially. We're going to be able to cache test results so we don't have to keep running the same tests over and over. We're going to eliminate dependency conflicts as a thing. We're going to have a nice story for doing typed durable storage without any sort of boilerplate, like writing JSON encoders and decoders."

Unison has been designed to be well-suited for distributed systems, because it allows a single program to describe its own deployment across multiple nodes rather than having multiple copies of the same code coordinating with each other across nodes.

As Bjarnason said in a presentation last year, "Unison can transfer an arbitrary computation, including its dependencies, to a remote node."

Unison hasn't quite come together yet. Many of the language's features and capabilities remain under development. But there's enough there to explore. ®