Bend Programming Language: What You Can Build with Bend 2
Explore the Bend programming language through five Bend 2 projects: a Doom recreation, an SVG editor, a database, a fractal explorer, and an HTTP server.
A programming language gets more interesting when someone builds something you can inspect. With Bend 2, that includes a recreation of Doom's first level, an SVG editor, a storage engine, and a Mandelbrot explorer.
If you've been reading about the Bend programming language and wondering what lies beyond the parallel-computing demos, these projects are a useful starting point. Each has public source code, and each uses Bend for a different kind of work.
First, one distinction matters: this article covers Bend 2. The current official Bend repository explicitly says that Bend 1 programs and HVM do not carry over. An older tutorial may describe a different language and toolchain from the one these projects use.
Project descriptions checked on September 24, 2026; toolchain check updated October 9, 2026. Project descriptions are based on their repositories and documentation, not independent runtime benchmarks.
What is the Bend programming language?
Bend 2 combines a programming language with a proof-checking workflow. Its Python-like surface syntax sits over a system with dependent types: types that can express properties of values, rather than just broad categories such as strings or numbers.
The practical idea is to state a rule your program should obey, then supply a proof that the implementation satisfies it. Bend's official workflow uses LAWS.bend for those rules and PROOF.bend for their proofs. The Bend website demonstrates this with a game rule that must remain true after the code changes.
For a developer, the important question becomes: which behavior have we actually specified and checked? A proof of one property is not a promise that every part of an application is correct. An incomplete specification can leave important behavior uncovered.
Want to see a proof check before installing a compiler? Bend, Explained offers a browser demo with editable code. Choose Original, then Run the checks; repeat with Refactor slip. In our October 16 check, the original passed and the faulty refactor failed. Raise the limit to 1500 passed too: changing code does not necessarily break a law.
The demo bundles Bend 2.0.25's ordinary checker, not the separate --verdict kernel check. Its animated CPU/GPU rounds are illustrations, not speed measurements. See the demo's version and limitations before treating it as a development tool.
Bend also targets parallel computation. Its current compiler supports C, Metal, CUDA, and JavaScript, although the JavaScript target runs sequentially. The official limitations describe a young toolchain, including restrictions on parallelism and unresolved compiler and proof-system concerns. That makes concrete projects especially valuable: they show the implementation choices behind the headline capabilities.
Try a browser editor before installing
To write or edit a small program without a local toolchain, open the Bend 2 pocket workshop. Unlike the guided explainer above, this is an editable workspace with bundled examples.
In Examples, choose x + 0 = x, then press Check. Built with Bend repeated this path on November 6, 2026, in desktop Chromium at 390 px and 1440 px: the ordinary checker accepted the bundled law and proof. The workshop reported Bend 2.0.39, matching its compiler pin.
This exercise needs no AI-provider key. It does not run the CLI's separate --verdict kernel check. Read the workshop's source and setup notes before moving beyond the bundled example.
Check your Bend version before trying a project
Bend 2 is a different language from the earlier HVM-based Bend. Before copying a tutorial's commands, compare its toolchain with the project's README. A .bend filename alone doesn't establish compatibility.
For example, the archived Bend 0.2.38 README installs HVM2 and the bend-lang Cargo package. Those instructions belong to the older toolchain; they are not the installation instructions for these Bend 2 projects. HVM2's “2” does not mean Bend 2.
Start with the current official installation instructions, then check your local executable. We checked these commands with Bend 2.0.35 on October 9, 2026; bend guide prints the guide bundled with that installation:
bend version
bend guide
Once the version matches the project's requirements, try this small check before debugging a whole application. Save it as check.bend. It uses the typed definitions documented in the official Bend 2.0.35 guide:
import Base
def main() -> U32:
42
Run bend check.bend, using that guide's file-execution command. In our Bend 2.0.35 check it printed 42. This is a basic toolchain check, not a benchmark or proof that a larger project will build. A value-returning main is normalized by the checker; native applications can use a different execution path.
If this works but a project does not, check its pinned Bend release, platform requirements, and native dependencies next. Don't assume a successful tiny program establishes GPU support. Then choose one of the projects below and follow its own setup instructions.
Five Bend 2 projects worth exploring
These aren't ranked from best to worst. Pick the one closest to the kind of software you want to understand.
1. Bendoom: a game with simulation rules to inspect
Bendoom recreates Doom's E1M1 level in Bend 2. Its repository documents combat, doors, pickups, sound, music, and gameplay recording with video export. It offers releases for Linux and Apple Silicon macOS, while noting that macOS gameplay and audio still need hardware testing.
The useful learning material isn't just the familiar game. The repository separates out Bend source and includes LAWS.bend and PROOF.bend for simulation invariants. That gives you somewhere concrete to look when asking how a game describes rules that should survive later changes.
Start with the simulation laws, then find the corresponding game behavior. Which properties are formalized? Which behaviors are checked by tests or comparison with a reference implementation? Those are more revealing questions than simply asking whether the whole game is “proven.”
Explore it for: game logic, simulation invariants, and a substantial Bend application. Read the Bendoom source and README.
2. Bend SVG Studio: an editor that does its own rendering
Bend SVG Studio is an SVG viewer and editor with native and browser interfaces. The project implements SVG parsing, geometry, painting, rasterization, hit testing, and editing in Bend.
Its browser interface has an unusual boundary: the browser displays PNG frames generated from Bend-rendered pixels. It isn't handing the SVG document to the browser's own SVG renderer. Both interfaces use a shared document reducer, which handles changes to the editor's state.
This makes it a useful project for studying how an application separates its document model from presentation. Follow an edit from the interface through the shared state and into the resulting image.
The README documents incomplete SVG conformance, CPU rendering, and a macOS requirement for the native window. Treat it as an implementation to study, not a drop-in replacement for every SVG engine.
Explore it for: parsing, rendering, editor state, and shared application logic. Read the SVG Studio source and README.
3. MyLSM: an experimental storage engine
MyLSM is a log-structured merge-tree key-value store implemented in Bend 2. The project includes durable-storage machinery such as a write-ahead log, SSTables, compaction, and recovery.
It's an interesting change of pace from graphics demos. Storage forces you to think about what happens after a write, a deletion, a restart, or a failure—not just whether a computation returns the expected answer once.
MyLSM also distinguishes its pure, in-memory library interface from the repository's durable-storage implementation. Its documentation keeps storage I/O on the CPU; GPU execution applies only to suitable pure computation.
The project's correctness notes are worth reading alongside the code. They distinguish existing proof witnesses and executable checks from general properties and host I/O behavior that still need stronger validation. The README also identifies remaining work before making production or competitive claims.
Explore it for: storage architecture and the boundary between checked computation and external effects. Read the MyLSM source and README.
4. Bend 2 Mandelbrot: GPU computation inside a native application
Bend 2 Mandelbrot is an interactive fractal explorer for Apple Silicon Macs. It supports zooming, panning, coloring, and deep-zoom experiments.
The implementation matters as much as the image. Bend GPU code handles ordinary-depth rendering, while dedicated Metal kernels handle the multiprecision rendering path. It is a mixed-language application, not evidence that every part of a native interface or deep-zoom algorithm comes from Bend alone.
That boundary is useful to study. Where does Bend express the computation, where does the project use platform-specific code, and what happens when a user changes the view before rendering finishes?
The repository documents its Apple toolchain requirements and distinguishes rendering modes. Check those before trying it on your own machine.
Explore it for: GPU workloads and integration with a platform-specific application. Read the Mandelbrot source and README.
5. Bend HTTP Server: separating requests from computation
Bend HTTP Server is a focused HTTP/1.1 server experiment. Its layout separates socket operations from request parsing, response formatting, routing, and computation.
It includes routes that perform a fork-join computation on the CPU or dispatch it to the GPU. The accompanying laws and proofs address agreement between the computation paths. This is a useful example of choosing a specific property to check, rather than making a blanket claim about server correctness.
The project also makes an important development distinction: running through the JavaScript backend is single-threaded. Native compilation is needed for the demonstrated multicore and GPU execution paths.
Read this as a small server implementation, not a complete web framework. Its value is that the boundaries are visible: parsing and routing on one side, socket effects on another, and an isolated workload to experiment with.
Explore it for: server structure and CPU/GPU computation behind an HTTP interface. Read the HTTP server source and README.
For a runnable starting point, use the tested Bend 2 HTTP-server walkthrough. It compares the official local demo with Bendo's wildcard hello and checks unwanted paths and methods, without claiming the community compute server was run.
How to choose your first Bend 2 example
Choose one question before choosing a repository:
- How do I express a rule about changing application state? Start with Bendoom's simulation laws.
- How can two interfaces share an application core? Follow SVG Studio's document reducer.
- What sits outside a proof about pure code? Compare MyLSM's computation and storage-I/O boundaries.
- How does Bend fit alongside native GPU code? Trace the Mandelbrot rendering paths.
- How do requests reach parallel computation? Follow the HTTP server's routing and compute modules.
Then narrow the reading to one behavior. Trace its input, implementation, and output. If there is a law, inspect what it says before reading the proof. If there is a performance claim, look for the workload, execution mode, hardware, and measurement method.
You don't need to understand the entire repository to learn something useful from it.
Where to go next
For language syntax and installation, start with the official Bend site and its linked guide. For project setup, follow the chosen repository's own requirements: examples may depend on a particular toolchain version or operating system.
Before reading or changing a project's source, compare Bend 2 editor tools for VS Code and other LSP clients. The guide separates editor integration from the compiler so you can choose a setup that fits your workflow.
For more applications to read, browse the Built with Bend directory. It links builds to their sources so you can move from “someone made this” to “here is how it works.”
Already building something with Bend 2? Submit your build so other developers can learn from it.
For a hands-on distinction between a law, an ordinary checker pass and additional kernel validation, try the Bend 2 proof workflow and its failure controls. The worked result includes a failed --verdict attempt, not a kernel-validation claim.