mutable names + semver negotiation
Verified refs: term + type decide identitygleam · unison ideas · beam reality
Code should move like data and upgrade like a living system.
GleamUnison exists because names, packages, and deployments are the wrong unit of identity for distributed software. It makes definitions content-addressed, typed, sandboxable, syncable, and executable on the Erlang VM.
typed hash is the addressBEAM is the engineabilities are the boundary
the case
Software deployment is still pretending source files are the thing.
They are not. The thing you actually care about is a verified definition: its structure, its type, its effects, its dependencies, and the exact runtime behavior that falls out. GleamUnison turns that definition into the address. If the code changes, the identity changes. If it does not, the identity does not. Simple. Brutal. Useful.
the replacement
Stop coordinating names. Start verifying structure.
ship the whole box for one behavior change
Pull only missing definitions by hashambient authority or slow sandboxes
Native BEAM processes with explicit abilitiesrestart the world and hope state survives
Load new behavior beside living actorsHot upgrades still fight names
Classic BEAM releases are powerful, but module names and two-version limits make long-lived stateful actors awkward to evolve safely.
Plugins are either trusted or slow
Most systems choose between native speed with too much access, or sandboxed interpreters with disappointing throughput and weak integration.
Distributed code is usually packaging theater
Shipping a container because one function changed is waste. GleamUnison syncs verified definitions by hash and loads only what is missing.
the move
Hash the typed definition. Load the hash. Sync the hash.
Text enters as S-expressions, elaborates into Gleam data, receives an inferred type, hashes into a content-addressed ref, persists in ETS/DETS/Mnesia, compiles through Erlang source into BEAM bytecode, then loads as a module named from the hash.
- parse
- elaborate
- infer
- hash
- store
- compile
- load
- run
Identity
Term + inferred type are hashed together. Names become metadata; code becomes immutable, auditable structure.
Runtime
Definitions compile to hash-named BEAM modules, giving OTP isolation, scheduling, supervision, and dynamic loading.
Effects
Algebraic abilities make IO explicit, interceptable, and host-controlled instead of ambient and terrifying.
Sync
Nodes exchange roots, pull missing refs, verify hashes, persist them, then execute the same code by construction.
where it is most useful
The sweet spot is code that must evolve while it is running.
GleamUnison is not trying to replace every app framework. Good. Frameworks are boring. It is for runtimes, agents, plugin systems, edge nodes, distributed workflows, and long-lived actors where identity, mobility, auditability, and controlled effects matter.
Stateful actor upgrades
Swap the behavior of a live process without losing mailbox state, sockets, or conversations.
Tenant-safe extensions
Run customer code inside BEAM processes while abilities decide what file, network, DB, and clock access exists.
Edge job stealing
Ship compact verified work units by hash; remote nodes pull dependencies and execute native BEAM bytecode.
Auditable event replay
Record events with the exact handler hash so history can be replayed against the code that actually ran.
Dynamic API gateways
Route requests to content-addressed handlers that can be compiled, loaded, rolled forward, or inspected independently.
IoT and small-runtime patching
Send function hashes instead of firmware images; update behavior without resetting the device or bloating the payload.
identitySHA256(term + inferred type)module loadingm_<hash> on the BEAMstorageETS · DETS · partitioned DETS · Mnesiasyncpull missing refs, verify, load
why this is different
Unison gives content-addressed code. BEAM gives living processes. GleamUnison welds them together.
The result is a runtime where immutable definitions can be shipped like data, executed like native BEAM modules, constrained by abilities, supervised by OTP, and audited by hash. That combination is the point.
proof, not vibes
Dogfooded until the cute idea became a pressure-tested runtime.
5,696+playbook conformance levels pressure-test the runtime pipeline
53unit tests across hashing, storage, inference, compiler, effects, sync, and jets
~1.2MBstandalone escript runtime when Erlang/OTP is already installed
52genesis modules bundled as content-addressed primitives
bottom line