Unison

Unison is a purely functional, statically typed language built around one radical idea: code is not text. Every function in a Unison codebase is identified by a cryptographic hash of its syntax tree — a 512-bit SHA-3 digest of the implementation itself — rather than by a name in a file. Names are just human-friendly labels attached to hashes. From that single decision falls an entire cascade of consequences: no builds, no dependency version conflicts, instant and risk-free renames, perfectly cached test results, and — the project’s ultimate goal — the ability to ship an arbitrary computation, with all of its dependencies, to another machine at runtime. Unison bills itself as “a friendly programming language from the future,” and it reads like one: a language where deploying a distributed system feels like calling a function.

History & Origins

A Decade-Long Bet

Unison began in 2013, when Paul Chiusano — coauthor of the influential book Functional Programming in Scala — left full-time work to research what a programming language would look like if it were designed from scratch for distributed computing. He funded the early years through consulting, doing language research between client engagements. The question driving the work: modern software runs across many machines, yet every mainstream language still assumes a single computer. What would you build if you didn’t?

The project became public in earnest in 2019, when Unison — open source, written in Haskell — entered public alpha and Chiusano presented it at the Strange Loop conference. The work is stewarded by Unison Computing, a public benefit corporation cofounded by Chiusano, Rúnar Bjarnason (his Functional Programming in Scala coauthor), and Arya Irani. The company’s charter commits it to the open-source language while it builds a commercial cloud platform on top.

The road from alpha to stable took six years of milestone releases: the M2 milestone in 2021 rebuilt the codebase storage on SQLite (roughly 100x smaller on disk, according to the project’s release notes), the 0.5.x series matured the tooling through 2025, and Unison 1.0.0 shipped on November 25, 2025, declaring the language, distributed runtime, and developer workflow stable.

Design Philosophy

The One Big Idea: Content-Addressed Code

In every mainstream language, a program is a bag of mutable text files, and names are load-bearing: renaming a function, moving it between modules, or upgrading a dependency can break the build. Unison abolishes this. Each definition is parsed, type-checked once, and stored in a database keyed by the hash of its abstract syntax tree. Two functions with identical structure are literally the same function, whatever they’re called.

The consequences are striking:

• No builds. A definition is type-checked when it enters the codebase and never again. There is no compile step over a project; there is nothing to recompile.
• No dependency conflicts. Two libraries can depend on “different versions” of the same function without collision, because each version is a distinct hash and both can coexist.
• Renames are free. Renaming updates a name-to-hash mapping; no code that referenced the hash changes, so nothing can break.
• Caching all the way down. Test results are cached against the hashes of the code they exercise — if nothing a test depends on changed, the test provably doesn’t need to re-run.
• Code can travel. Because a function’s identity is its hash and its dependencies are hashes too, a running program can serialize a computation and send it — with any missing dependencies — to another node, which is the foundation of Unison’s distributed programming story.

Abilities: Effects Without Monads

Unison is purely functional, but instead of Haskell-style monads it manages side effects with abilities — its implementation of algebraic effects, based on the Frank language described in Sam Lindley, Conor McBride, and Craig McLaughlin’s 2017 paper “Do Be Do Be Do.” A function’s type tracks which abilities it requires ({IO, Exception}, say), and handlers interpret those requirements — meaning the same business logic can be run against real I/O in production and a pure in-memory handler in tests. Abilities compose without the monad-transformer machinery that famously complicates effectful Haskell code, and they are the mechanism through which Unison expresses everything from exceptions and state to distributed execution on remote nodes.

The Codebase Manager

Because code lives in a database, you don’t edit “the project” in place. The Unison Codebase Manager (UCM) watches a scratch file; you write or edit definitions there, UCM type-checks them as you save, and an update command commits them into the codebase. UCM then does the refactoring bookkeeping that text-based languages force onto programmers, tracking every place a changed definition is used and guiding the codebase from one well-typed state to the next — there is no moment when the codebase as a whole “doesn’t compile.” The ecosystem’s sharing model is native too: libraries are published to Unison Share as content-addressed definitions, not tarballs, and installing one can never conflict with anything already present.

A Taste of Unison

Hello World shows two signatures of the language at once — abilities in the type, and the ' delay syntax marking a computation that hasn’t run yet:

helloWorld : '{IO, Exception} ()
helloWorld _ = printLine "Hello, World!"

Defining and handling a custom ability looks like this:

-- An ability that provides a source of configuration text
ability Ask where
  ask : Text

-- Business logic that uses the ability, with no idea where the value comes from
greet : '{Ask} Text
greet _ = "Hello, " ++ ask ++ "!"

-- A pure handler that supplies the value
provide : Text -> '{Ask} a -> a
provide answer computation =
  handle computation() with cases
    { result }        -> result
    { ask -> resume } -> provide answer '(resume answer)

test> greeting.test = check (provide "world" greet == "Hello, world!")

The test> watch expression’s result is cached against the hashes of everything it touches: it re-runs only if greet, provide, or their dependencies actually change.

Key Features

• Content-addressed definitions — code identified by SHA-3 hashes of its syntax tree; names are metadata
• Abilities — algebraic effects for I/O, exceptions, state, and distributed execution, checked in the type system
• No builds, no dependency hell — definitions type-check once; conflicting “versions” coexist as distinct hashes
• UCM and structured refactoring — the codebase manager keeps the codebase permanently well-typed through updates
• Unison Share — first-class code publishing with rendered docs and hash-linked source browsing
• Distributed computation — serialize any value, including functions and their dependencies, and run it on another node
• Typed durable storage — persist arbitrary values, functions included, without serialization boilerplate
• Modern tooling — LSP support, the UCM Desktop app, an official Docker image, and an MCP server for AI coding agents

Officially supported platforms (per the project’s installation documentation) are macOS on Intel and Apple Silicon, 64-bit Linux, and Windows, with Homebrew, APT, Nix (via community packaging), and manual installs available alongside the unisonlang/unison Docker image.

Evolution

Unison’s development has been unusually deliberate — roughly six years from first research to public alpha, then six more to 1.0. The public arc runs from the 2019 alpha through the 2021 M2 storage rewrite, the maturing 0.5.x UCM series, and the October 2023 early-access debut of Unison Cloud, the company’s managed runtime where deploying a distributed service is, in the language’s signature phrase, “just a function call.” Cloud launched publicly in February 2024, and that June the company announced $9.75 million in seed funding from investors including Amplify Partners, Uncork Capital, Good Growth Capital, and Bloomberg Beta. Unison 1.0.0 arrived on November 25, 2025, and the 1.x line has kept a brisk pace since — 1.3.0 landed in May 2026 with additions such as P-256 ECDSA cryptography builtins.

Current Status

Unison in mid-2026 is a small but unusually vibrant ecosystem: an actively developed open-source language (over 26,000 commits on GitHub), a growing library ecosystem on Unison Share with more than a thousand project authors, a commercial cloud platform with a bring-your-own-cloud option, an Exercism learning track, and coverage in venues from LWN to Strange Loop. It remains a niche language — adopting it means adopting a genuinely different workflow, since code lives in a managed codebase rather than text files, which is also why mainstream editor-and-git habits don’t transfer directly. That trade is exactly the point: Unison asks what programming looks like when the fifty-year-old assumption of code-as-text is dropped, and it is the most complete working answer to that question available today.

Why Unison Matters

Most new languages compete on syntax, performance, or safety within the established model of compiling text files. Unison is one of the very few that changes the model itself. Its content-addressed core dissolves an entire category of problems — builds, dependency conflicts, breaking renames — not by managing them better but by making them structurally impossible, and it turns “ship this computation to another machine” from an ops project into a language primitive. Whether or not Unison itself reaches mass adoption, it is a live demonstration that the pain of builds and dependency hell is a consequence of storing programs as text, not an inherent property of programming — an idea future languages will find hard to unsee.