Bend2 vs Bend1: what changed
Last updated .
Bend2 is the unreleased successor to Bend, called Bend1 here. Bend1 is public, installable, and most instructive for where it stopped. Bend2, per creator Victor Taelin’s public statements, keeps the execution model, replaces the runtime generation, and adds a type system. It is expected around 2026-08-12.
What Bend1 proved
Bend1, launched May 2024, demonstrated that recursion and algebraic data types written in a Python-flavored syntax, with no annotations of any kind, could saturate a GPU. The HVM2 runtime evaluates programs as interaction nets, where every reduction step is a local rewrite of two adjacent graph nodes. Independent rewrites cannot conflict, so parallelism is a scheduling decision rather than a language feature. A tree fold fanning out across thousands of threads with zero pragmas was a genuine first at this level of ergonomics, and that demo is why the launch thread got the attention it did.
Where the costs were
Bend1’s limits were mostly consequences of one design decision: represent everything as
interaction-net nodes compact enough to move through memory fast. Numbers were 24-bit (u24,
i24, f24) because the node encoding budgets its bits for tags and ports first, and
immediates get what remains. Graph memory was capped in the low gigabytes by fixed-width arena
addressing. IO stayed minimal because pure graph reduction has no natural place for effects, and
the effect boundary had not been built. Evaluation was strict only: HVM1 had been the lazy,
optimal-reduction line, and HVM2 traded that away for a model that mapped onto GPUs. On top of
all this sat a large constant factor, so a single tuned CPU core could beat impressive-sounding
GPU throughput on many workloads. People benchmarked an existence proof as if it were a product,
and the resulting criticism defined the successor’s todo list.
What Bend2 keeps
Bend2 keeps the thesis of parallelism by default on the interaction-net substrate, now four runtime generations in, with HVM4 public and pushed into mid-2026. Per Taelin’s 2026-07-18 posts, Bend2 ships Metal and CUDA backends, with the CUDA port implemented overnight by a coding model from the reference Metal runtime, reusing most of the existing code and running faster than Metal on RTX, which he put at roughly 10x parallel C for most programs. A working reference implementation is an executable spec plus a free differential test oracle, which is what makes that kind of port tractable for a model. The choice that carried the risk was writing the Metal backend well enough to serve as the oracle.
What Bend2 claims to add
Bend2’s headline addition is dependent types in the tradition of Higher Order Company’s Kind: types that can mention values, so “a sorted list” or “a parser that round-trips with this printer” is a type, and the checker rejects implementations that do not satisfy it. Two consequences matter to working engineers. Proofs can replace whole categories of tests, and types precise enough to pin down behavior make generated code checkable, which is where the synthesis component, named SupGen in Taelin’s launch-blocker list, fits. Public posts from mid-2026 also describe the checker as TypeScript running under Bun after a July migration, which, if accurate, says something about who the toolchain is built to reach. Whether the 24-bit numbers, the memory ceiling, and the IO story actually improved is unknown, and those are the first three things to verify against the compiler on release day.
Which to use today
Bend1 is the only Bend that runs as of 2026-08-04, and for workloads that fit inside 24-bit numbers and minimal IO it remains a working demonstration of automatic parallelism: github.com/HigherOrderCO/Bend. Bend2 is a set of claims until code lands. The front page flips the day that changes.