# HigherOrderCO/HVM1: a beta-optimal functional runtime in Rust, and what it is not

> HVM1 is a lazy, non-garbage-collected, massively parallel functional runtime built on interaction nets. It is a prototype, and the README says so.

**HigherOrderCO/HVM1** — HVM1 (2022): a massively parallel, optimal functional runtime in Rust

- Repository: https://github.com/HigherOrderCO/HVM1
- Website: https://higherorderco.com
- Stars: 11,347 · Forks: 437
- Language: Cuda
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/higherorderco-hvm1

## What HVM1 is, and who the README is talking to

HVM1 is a pure functional runtime. The README describes it as lazy, non-garbage-collected and massively parallel, and adds a fourth property: beta-optimal, meaning that for higher-order computations it can, in some cases, be exponentially faster than alternatives such as GHC. The mechanism behind that claim is a model of computation called the Interaction Net, which the README presents as superseding the Turing Machine and the Lambda Calculus. Earlier implementations of interaction nets were inefficient in practice; the README attributes HVM's existence to a recent breakthrough that made them fast enough to matter.

The audience is narrow and specific. This is not a general-purpose language for application developers. It is a runtime and a minimalist functional language that compiles to it, aimed at people who care about evaluation order, parallelism and asymptotics. The README's own framing is unusually direct about status: "The code here is a prototype, but the first production ready version is coming soon, with tons of optimizations and - most importantly - correctness work." It then points readers to HVM-Core. That sentence should shape every decision you make about this repository. The project is a research artifact with a documented successor, not a finished tool.

## Interaction nets and why bubble sort does not get faster

The runtime turns a functional program into a network of interaction nodes and reduces it by rewriting. The README's two worked examples show what that buys and what it does not.

Bubble sort is the negative case. The README runs the same recursive algorithm in HVM and in GHC, and reports that both perform similarly, with HVM having a small edge. The important line is the next one: performance does not improve with added cores, because bubble sort is inherently sequential. The chart shows GHC single-threaded and HVM at 1, 2, 4 and 8 threads, and the extra threads do not help. This is the honest part of the README. Automatic parallelism is not a property of the runtime alone; it depends on whether the algorithm exposes work that can be reduced independently.

Radix sort is the positive case. The HVM program builds a tree-shaped Map from the input, merges it in a way that splits into independent sub-merges, and converts it back to an array. The merge function recurses on both children at once, which is the shape that gives the runtime something to do in parallel. The same structure appears in the Haskell version, so the comparison is between runtimes on an identical algorithm rather than between two different programs. If you want to understand where HVM1's parallelism comes from, read the radix sort example first and the bubble sort example second.

## Building HVM1 from source and running a first program

There are no published releases in the repository, so the path is to build from source. The Cargo.toml declares the package as hvm1, version 1.0.12, edition 2021, MIT licensed, with a binary target also named hvm1 and a library crate type of cdylib and rlib. The repository pins its toolchain in rust-toolchain.toml, so a rustup-managed toolchain will follow that pin automatically.

Clone the repository and build the release binary. The README does not print this command, but Cargo.toml defines the binary target, and BUILDING.md is the file the repository provides for build instructions.

```bash
git clone https://github.com/HigherOrderCO/HVM1
cd HVM1
cargo build --release
```

The build produces the hvm1 executable under target/release. The repository also ships a Nix setup (flake.nix, default.nix, shell.nix, NIX.md) for readers who prefer a pinned environment; NIX.md is where that path is documented.

The examples directory is the place to start. It contains subdirectories for hello, lambda, sort, queue, callcc, IO and bugs, plus an examples/README.md. The sort examples are the two programs discussed above, at examples/sort/bubble/main.hvm and examples/sort/radix/main.hvm. The README gives the source of both, so you can read the program before running it. The guide/ directory holds the longer documentation. HOW.md, at the repository root, is the file to read if you want the runtime's own account of how reduction works.

One caveat worth stating plainly: the README does not document command-line flags, so do not assume a flag exists because it would be convenient. Check the CLI's own help output or the source under src/ before scripting anything around it.

## The prototype problem, and the correctness work still pending

The README is candid that correctness work is pending, and that is the limitation that matters most. A runtime whose evaluation model differs from the lambda calculus is hard to validate: two programs that should be observationally equivalent can diverge in ways that are not obvious from the source. The repository even keeps an examples/bugs directory, which tells you the authors track known misbehaviour in-tree rather than pretending it does not exist.

The second limitation is algorithmic. Beta-optimality is described as applying "in some cases" to higher-order computations. Bubble sort is the counterexample in the README itself: identical algorithm, no scaling with cores. If your workload is sequential, or if its parallelism is not expressible as independent interaction-net reductions, HVM1 gives you nothing over a mature compiler, and you pay the cost of an unfamiliar language and a prototype runtime.

The third is ecosystem. There is no package registry entry to depend on, no released artifact, and the README directs readers to HVM-Core for the production-ready line. Adopting HVM1 means adopting a moving target whose successor already exists. That is a reasonable choice for research and unreasonable for a service you have to keep running.

## HVM1 against GHC, and against HVM-Core

The README's own comparison is with GHC, and it is a fair one because the two sort programs are line-for-line equivalent. The difference in approach is fundamental. GHC compiles a lazy functional language to native code and relies on a garbage collector and a runtime that manages sharing and updates; HVM1 eliminates the collector entirely by using interaction nets, where reduction is local rewriting and unreachable nodes are simply never touched again. That is why the README can claim no GC is needed.

The cost of that design is that you write in HVM's minimalist language rather than Haskell. The README's bubble sort example is written in a syntax that looks like a cross between a term-rewriting system and a functional language, with rules like (Sort Nil) = Nil and (Sort (Cons x xs)) = (Insert x (Sort xs)). There are no type classes, no modules in the Haskell sense, and no library ecosystem to draw on. You are trading a mature toolchain for a model of computation.

The second comparison is internal, and more consequential for anyone deciding today. HVM-Core is the successor the README names for the production-ready version. Choosing between them is not a matter of features; it is a matter of whether you want the 2022 prototype documented here or the line the authors describe as carrying the correctness work. For new work, the README's own pointer answers the question.

## Maintenance, upgrade cost and the MIT licence

The repository is not archived, and its last push was on 2026-09-16. That is recent enough that the code is not abandoned, but the README's description of the code as a prototype, combined with the pointer to HVM-Core, means the maintenance question is really a migration question. The interesting work is happening on the successor, and the version string in Cargo.toml (1.0.12) with no published releases suggests the 1.x line here is not where new capability lands.

Upgrade cost is therefore not the usual dependency-bump exercise. There is no registry package to pin, so you vendor the source or track the repository directly. The rust-toolchain.toml pin means the compiler version moves with the repo, and the dependency set (HOPA, clap 3.1.8, crossbeam 0.8.2, sysinfo 0.29.10 and others) will age with it. If you build against HVM1 and later move to HVM-Core, expect to rewrite your programs, not just your build files, because the runtime is the interface.

The licence is MIT, declared in Cargo.toml and present as LICENSE at the repository root. MIT is permissive: it allows use, modification and redistribution with the copyright notice and permission notice retained. That is the extent of what the repository states. Whether MIT fits your organisation's policy, and what obligations attach to redistributing a binary, is a question for your own legal review rather than something the repository answers.

## Conclusion

HVM1 is worth your time if you want to run interaction-net programs and read the source of a beta-optimal runtime, and you accept that the README itself calls the code a prototype. It is the wrong choice if you need a supported production runtime: the README points to HVM-Core for the first production ready version, and the repository carries no releases. Before adopting anything, read HOW.md, BUILDING.md and NIX.md, then run cargo build --release and the examples/hello program on your own machine to see what the runtime actually does on your hardware.

## FAQ

### What is HVM1?

HVM1 is a pure functional runtime that the README describes as lazy, non-garbage-collected, massively parallel and beta-optimal, built on a model of computation called the Interaction Net. It is written in Rust and released under the MIT licence.

### Is HVM1 production ready?

No. The README states plainly that the code is a prototype and that the first production ready version is coming soon, with correctness work still to be done, and it points readers to HVM-Core for that line.

### How do I install HVM1?

There are no published releases, so you build from source: clone the repository and run cargo build --release, which produces the hvm1 binary from the target declared in Cargo.toml. The repository also ships a Nix setup documented in NIX.md.

### Does HVM1 get faster with more CPU cores?

Only when the algorithm exposes independent work. The README's bubble sort example shows no improvement from 1 to 8 threads because bubble sort is inherently sequential, while the radix sort example is built around a merge that splits into independent sub-merges.

## Sources

- [HigherOrderCO/HVM1 on GitHub](https://github.com/HigherOrderCO/HVM1)
- [Issues](https://github.com/HigherOrderCO/HVM1/issues)
- [License: MIT](https://github.com/HigherOrderCO/HVM1/blob/master/LICENSE)
- [Project website](https://higherorderco.com)
- [README](https://github.com/HigherOrderCO/HVM1/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/higherorderco-hvm1