Unison is a statically typed functional programming language that takes a fundamentally different approach to how code is stored, compiled, and versioned. Instead of identifying functions by their names and storing source files as text, Unison identifies every function by a cryptographic hash of its implementation. The codebase is a database of abstract syntax trees, not a collection of files. That design choice eliminates several categories of problems that conventional languages treat as inevitable.
Content-Addressed Code and the End of Build Times
In most languages, changing a function's name or moving it between files triggers recompilation across everything that depends on it. Unison does not have this problem because functions are identified by their content, not their name. Renaming a function is instant and non-breaking because the hash does not change. Moving a function between modules changes its fully qualified name but not its identity. The compiler never needs to rebuild anything from scratch because the shared compilation cache is part of the codebase format itself.
The practical effect is that Unison has perfect incremental compilation. Despite strong static typing and an effect system, developers almost never wait for code to compile. The compiler processes only the parts that actually changed, and the results are cached permanently in the codebase. There is no build step in the traditional sense. You modify a definition, and the updated version is immediately available.
How the Language Works
Unison uses type inference, so function signatures can be omitted and the compiler will deduce them. Function arguments are separated by spaces rather than parentheses and commas. Loops are written through recursion rather than dedicated loop constructs. Pattern matching works through match expressions and applies to both built-in types like lists and user-defined data types.
A factorial function in Unison looks like this: the signature Nat -> Nat appears before the definition, the function takes a single argument, and the body computes the product of a range. A list map function uses a nested helper function to implement recursion, matching on the list structure with pattern matching syntax. The language supports anonymous functions for inline transformations, and the interactive environment evaluates expressions immediately, showing results in the same session.
Unison can be used as a general-purpose language for any programming task. It also integrates with Unison Cloud for building distributed systems, where the content-addressed code model provides additional benefits for deployment and service composition.
Semantically-Aware Version Control
Traditional version control tracks text diffs, which means reformatting code, reordering imports, or changing whitespace all produce merge conflicts even when the semantics are identical. Unison's content-addressed approach avoids this entirely. Two versions of a codebase that differ only in formatting or import order are treated as equivalent because the underlying function hashes have not changed.
Tests are cached with the same precision. Deterministic tests rerun only when their dependencies have actually changed. If a function's implementation hash has not been modified, its tests do not reexecute, regardless of what else changed in the codebase. This eliminates a significant source of wasted CI time in large projects.
Tooling and Development Environment
The Unison Codebase Manager (UCM) is the primary development interface. It starts a local web server that powers the Unison Local UI, providing a browser-based view of the codebase. The server selects a random port and unique token on startup, both configurable through environment variables. A language server is available for editor integration, and an AI agent server supports programmatic interaction with the codebase.
Building from source uses Stack. The project provides a dev UI install script that downloads the latest release of Unison Local UI and places it in the expected location for the executable created by the build process. Development documentation lists common build commands for contributors.
What This Means for Developers
Unison's content-addressed model solves real problems that developers encounter daily. Build times, rename refactors, merge conflicts from formatting, and redundant test reruns all disappear not through better tooling but through a different fundamental representation of code. The tradeoff is that Unison requires buying into a different mental model. There are no source files in the traditional sense, and the codebase is a database you interact with through the UCM rather than a directory tree you navigate with cd and ls.
For teams considering Unison, the strongest argument is the elimination of entire categories of friction. The strongest counterargument is ecosystem maturity. Unison does not have the library breadth of established languages, and the content-addressed model means existing code cannot be trivially ported. The language is best evaluated on projects where the build and refactor benefits outweigh the ecosystem gap, particularly for codebases that change frequently and have complex dependency graphs.