HVM4, explained
Last updated .
HVM4 is Higher Order Company’s fourth-generation runtime and the substrate Bend2 is built on. It is public on GitHub: a C implementation of what its documentation calls the Interaction Calculus, created in November 2025 and pushed through mid-2026, with a README that opens “you’re here before launch. Use at your own risk.”
The model of computation
HVM4 evaluates programs as interaction nets: the program is a graph, and computation is a small fixed set of rewrite rules, each touching exactly two adjacent nodes. Locality buys two properties that conventional runtimes have to engineer for. Rewrites that share no nodes cannot conflict, so every independent redex can fire at once with no locks. And the rules are confluent, so the result does not depend on firing order, which means any idle core can take any available work. Parallelism stops being a language feature and becomes a scheduling decision. The recurring cost is the constant factor: each step is graph surgery with real memory traffic, and closing that gap is what the runtime generations have been about.
Superpositions
HVM4’s calculus has a primitive most runtimes lack: a term can be a superposition of two values. The README’s own example is compact enough to quote:
@main = (&{1, 2} + 10)
//11
//12One expression, two results, because &{1, 2} flows both values through the addition, sharing
all the work that does not depend on the choice. The dual primitive, duplication, lets one
value feed two uses without copying. Superpositions are how an evaluator explores many branches
of a search space while paying for the common structure once, which is the natural reading of
the name SupGen, the synthesis component on
Taelin’s launch-blocker list: program
generation as collapsing a superposition of candidate programs. That reading is mine, not his;
the primitives, at least, are in the repository today.
Four generations
HVM4 closes a lineage that has been public since 2022. HVM1
was the lazy, optimal-reduction evaluator that showed interaction combinators could be fast in
practice on CPUs. HVM2 went strict, compiled to C and
CUDA, and carried the original Bend at its
May 2024 launch, along with Bend1’s documented
limits: 24-bit numbers from the compact node encoding, a memory ceiling from fixed-width arena
addressing. HVM3 iterated through early 2026. HVM4
consolidates the line into a strikingly small artifact: the whole runtime builds with one
command, clang -O2 -o src/hvm src/hvm.c, and ships its
memory layout and
interaction rules as
documentation next to the code.
What the AOT compiler changes
HVM4’s ahead-of-time compiler was one of three items on Taelin’s 2026-03-05 launch-blocker list, and it targets the lineage’s known weakness. An interpreted evaluator pays dispatch overhead on every rewrite: fetch the node, branch on its kind, mutate the graph. Compiling a program’s rewrite rules ahead of time to native C removes the dispatch and lets the compiler specialize memory access per rule, which attacks exactly the constant factor that made a tuned CPU core competitive with Bend1’s GPU throughput. The second blocker, the GPU runtime, resolved in July: per Taelin’s 2026-07-18 post, the CUDA backend was implemented overnight by a coding model from the Metal reference and ran faster than Metal on RTX, a baseline he put at roughly 10x parallel C for most programs.
What HVM4 means for Bend2
HVM4 is the half of Bend2 you can read today. The language, the type checker, and SupGen remain private, but the runtime’s calculus, memory layout, and interaction rules are inspectable, and they constrain what the language above them can be: parallel by default, superposition-capable, compiled rather than interpreted. The repository carries no license text as of 2026-08-04, which is worth checking again at release. For the language side, start with What is Bend2?; for what the runtime lineage fixed and dropped along the way, Bend2 vs Bend1.