revo: a dynamically typed language written in Zig, built for experimentation

What revo is for, and who should care

revo describes itself as "an expressive, dynamically-typed language for the joy of programming." That phrasing sets the scope. This is not a language competing for production web services or data pipelines. It is a runtime for people who enjoy writing interpreters, who want a scripting layer inside a larger program, or who want to read a language implementation written in Zig.

The repository gives two concrete audiences beyond hobbyists. The first is embedders and extenders: the README states that you can extend revo in "(essentially) any language" or embed it from any language, with loadable extension APIs for two ABIs, Zig and C. The second is tooling users: an LSP is bundled by default with the revo binary, and a separate tree-sitter grammar exists for editor highlighting. Someone who wants syntax highlighting and diagnostics in their editor without writing a plugin from scratch is a legitimate user of this project.

The examples directory is the best signal of intended use. It contains files named json.rv, markov.rv, redis.rv, threads.rv, pipes.rv, plot.rv, proc.rv, and nbnet.rv. That is a snapshot of what the authors consider representative: text processing, a network client, concurrency, shell-style pipelines, and a graph. There is even a kernel, hachem-wtf/revel, listed under "made with revo." None of that implies production readiness, but it does show the language is exercised against more than arithmetic.

The interpreter, the LSP, and the doc generator

The architecture visible from the repository layout is a single Zig codebase under src/ that produces one binary, revo, with three roles. The first role is the interpreter itself, which the README shows launching into what appears to be an interactive session when you run the bare command. The second is an LSP server, described as "bundled by default with your revo," which supplies diagnostics and highlighting to editors. The third is a documentation generator, invoked as revo doc or revo doc --html against a file or directory.

That bundling decision has a clear trade-off. Putting the LSP in the same binary means there is no separate language-server package to install or version-match, which removes a common source of editor breakage. It also means the LSP cannot be updated independently of the interpreter, and any bug that crashes the binary is available to both your editor session and your scripts.

Extension happens through loadable extensions rather than a stable plugin protocol. The README points to examples/foreign/zig and examples/foreign/c for the two ABIs, and notes that embedding is a todo for both. So the current integration story is one-directional: foreign code can be loaded into revo, but revo is not yet documented as a library you link into a host program. If your plan is to call revo from inside a larger C application, the README does not describe how, and that gap is worth taking at face value.

Installing revo from source with Zig 0.16.0

The README states that the latest release is hosted on GitHub Releases, but it recommends building from source instead because "this project is rapidly changing." Take that recommendation seriously: the pinned dependency is Zig 0.16.0, and the README also suggests the anyzig version manager to get it.

On Linux, BSD, macOS and similar systems, the documented sequence clones the repository recursively, fetches build dependencies, and compiles a release build. The recursive clone and the explicit submodule update are both listed, which suggests submodules are load-bearing.

git clone https://github.com/if-not-nil/revo --recursive && cd revo
git submodule update --init --recursive
zig build --fetch
zig build -Doptimize=ReleaseSafe
cp ./zig-out/bin/revo ~/.local/bin/revo

The README documents two other optimize modes: ReleaseSmall produces roughly a 1 MB executable, and ReleaseFast gives what the README describes as a 5% to 10% performance gain while making bugs harder to report. After copying the binary, running revo with no arguments starts the interpreter. If you use Nix, the repository has a flake exposing revo as a package on default, and the README gives nix shell github:if-not-nil/revo?dir=extra/nix as the way to open a shell with it.

Windows is explicitly caveated. The README notes that some features are unavailable there and recommends WSL with the Linux steps. The native path clones without --recursive, builds with ReleaseFast, copies the binary to C:/tools/revo/bin, and then requires adding that directory to PATH through the Windows environment variable dialog. The README does not list which features are missing on Windows, only that some are.

For a first real use, the doc generator is the least risky thing to try, because it needs no runtime dependencies and its output is inspectable. Point it at a file or a directory:

revo doc --html ./examples

The README documents both revo doc <file or directory> and revo doc --html <file or directory>, so the plain form emits text and the flag emits HTML. If you want something more representative of the language, examples/demo.rv is the file the repository itself points at as a demo.

Where revo is the wrong choice

The README's own advice is the first limitation: the project "is rapidly changing," which is why it recommends building from source over downloading a release. Three releases landed within roughly six weeks, from 0.1.0a on 2026-07-24 to 0.1.2 on 2026-09-05. A version number below 0.2 with that release cadence means you should expect breakage between tags, and you should not assume a script written against 0.1.1 runs unchanged on a later tag.

Embedding is the second gap. The README lists embedding as a todo for both the Zig and C APIs, so the only documented integration direction is loading foreign code into revo, not hosting revo inside another program. If your requirement is a scripting engine you can call from a long-running C service, the documentation does not yet cover that path.

Windows feature parity is the third. The README states plainly that some features are unavailable on Windows and recommends WSL. That is an honest disclosure, but it means a Windows-native deployment is not something the project claims to support fully.

Finally, the licence is MIT, which is permissive, but the README's credits note that revo depends on isocline and lsp-kit, both MIT. Those are compatible with the project's own licence, though anyone redistributing a binary should read the licence files rather than rely on this summary. None of this is a reason to avoid revo for experimentation. It is a reason not to put it in a path where a broken tag takes down something you cannot rebuild.

How revo differs from Lua and other embeddable runtimes

The obvious comparison for a small dynamically typed language with a C extension API is Lua. The difference in approach is in what each project optimises for. Lua's documented strength is a small, stable core with a long history of embedding into host applications, and its C API is the primary interface rather than an add-on. revo inverts that: the loadable-extension API exists for C and Zig, but embedding is listed as a todo, so the integration direction is currently one-way. If your goal is to embed a scripting language into a host program today, the documented revo path does not cover it.

A second comparison is to other Zig-implemented interpreters, where the appeal is usually reading a modern implementation in a language with explicit memory management. revo fits that niche, and the Zig 0.16.0 pin means the build tracks a specific compiler release rather than a range. That is a real constraint: upgrading Zig before revo does will break the build.

The LSP bundling is where revo is genuinely different from a plain interpreter. Most small languages expect you to install a language server separately, or live without one. revo ships diagnostics and highlighting in the same binary, which lowers the cost of trying the language in an editor. The trade-off, noted earlier, is that you cannot update the server without updating the interpreter.

Maintenance, upgrades and the licence

The repository is not archived, and the last push was on 2026-09-17, three days before this writing. That is recent activity, but activity is not the same as stability, and the README's own warning about rapid change is the more useful signal for planning. The version history supports that reading: 0.1.0a, 0.1.1, and 0.1.2 within about six weeks.

The practical upgrade cost is the Zig toolchain. The README requires Zig 0.16.0 and suggests anyzig specifically so you can hold that version. If you build revo in CI, pin the toolchain and the revo tag together, and treat a Zig upgrade as a separate change from a revo upgrade. Because the project recommends building from source over using releases, your build step is part of your upgrade path, not an alternative to it.

The licence is MIT, stated in the README and present as LICENSE.txt at the repository root. That permits use, modification and redistribution with the licence notice retained. The bundled isocline and lsp-kit dependencies are also MIT according to the credits section. This is a summary of what the repository states, not legal advice; if you redistribute a binary, read LICENSE.txt and the dependency licences yourself.

Editorial conclusion

Adopt revo if you want a small dynamically typed runtime to embed, extend, or study, and you are comfortable building from source with Zig 0.16.0. Do not adopt it if you need a frozen toolchain, a stable ABI for embedding, or Windows parity with Linux. Before committing, build the tag you intend to ship, run revo doc --html over your own source tree, and check that the loadable extension path you plan to use (C or Zig) is the one the examples cover.

Frequently asked questions

Official sources

1. if-not-nil/revo on GitHub
2. License: MIT
3. Project website
4. README
5. Releases