Search: domain:unison-lang.org
1 post
1 post
At the heart of Unison is the idea that every code definition is identified by a unique cryptographic hash of its syntax tree, rather than its human-readable name. Names are treated merely as metadata pointers to these hashes. Because the syntax tree structure strips away specific naming variations and normalizes variables, a hash uniquely and immutably pins down a function's exact implementation and its dependencies.
On-the-Fly Dependency Syncing: Since definitions are identified by hashes, arbitrary computations can be shipped directly across a network. The receiving machine checks the bytecode for missing hashes, requests only what it lacks on the fly, caches them, and runs the computation.
Elimination of "Glue" Infrastructure: Network boundaries are handled naturally by the language. There is no need for complex out-of-band setups, container building, or writing tedious serialization/deserialization layers (JSON/YAML) to stitch separate programs together.
Permanent Compilation Cache: Because a definition's hash never changes, code is parsed and typechecked exactly once. The results are permanently cached in the codebase format, eliminating compilation wait times.
Deterministic Test Caching: Pure, deterministic test results are cached. If a function's hash and its dependencies haven't changed, the tests never need to be rerun.
Coexistence of Versions: Dependency conflicts (like the diamond dependency problem) occur when different definitions compete for the same name. Because Unison references code by hash, multiple versions of the same library or type (e.g., two different Email types) can coexist seamlessly in the same codebase.
Non-Blocking Upgrades: Developers can write functions to bridge or convert between different versions at their own leisure, without a dependency conflict breaking the build or halting work.
Automatic Serialization: Any value or function can be persisted and loaded without manually writing encoders, decoders, or schemas.
Guaranteed Deserialization: Since the serialized values are bound to immutable content hashes, deserializing data years later will always yield the exact same behavior, regardless of how the surrounding codebase has evolved.
Type-Safe Database Interoperability: Storage layers can be typed directly within the Unison language, ensuring compile-time type safety when interacting with persisted data.
Codebase as a Database: A Unison codebase is a structured database containing perfect dependency graphs and type indices, making features like type-based search and hyperlinked documentation exceptionally easy to build.
Decoupling Text from Storage: While developers still edit code as text, the codebase stores it in a structured format. This enables instant, codebase-wide renames that never break downstream users.
No Broken Codebase States: Refactoring in Unison means changing which hashes human-readable names point to.
Tidy "Todo" Lists: Instead of causing a cascade of compiler errors, the codebase manager creates a parallel workspace. The original program remains fully operational while Unison provides a precise list of name updates to resolve before cutting over to the new implementation.