Woxi and the case for a Rust rewrite of the Wolfram Language

A subset of the Wolfram Language, with the status of every function tracked

Woxi is an interpreter for the Wolfram Language powered by Rust, and its scope is stated up front: the initial focus is to implement a subset of the Wolfram Language so that it can be used for CLI scripting and notebooks.

That word, subset, is the whole design decision, and the project handles it in a way that is unusual and useful. There is a functions.csv file listing all Wolfram Language functions together with their implementation status, so a reader can look up whether the symbol they are about to call exists. There is a tests/cli directory with the currently supported commands and their expected output, and the requirement stated there is that all tests must pass with both Woxi and WolframScript. That is differential testing against the reference implementation, and it is the reason the project can claim parity on the parts it does cover rather than only on the parts its author preferred.

The intended users are people who already know the Wolfram Language and want a tool that starts instantly. The README states the reason Woxi is faster than WolframScript: there is no overhead of starting a kernel and verifying its license. For a script that runs in CI, on a build agent, or as a step in a longer pipeline, that startup difference is the whole argument, and the project is not trying to be a Mathematica replacement.

The primary language is Rust, and the licence field on the repository says AGPL-3.0, with the crate metadata in Cargo.toml reading AGPL-3.0-or-later. The repository is not archived, and the last push was on 2026-10-20.

eval, run and repl, with a shebang that starts a script directly

The command line is the primary interface, and it is small enough to learn in a minute. Evaluating an expression is one subcommand.

woxi eval "1 + 2"
# 3

A longer expression works the same way.

woxi eval 'StringJoin["Hello", " ", "World!"]'
# Hello World!

Scripts are run with a second subcommand, and the file extension in the examples is .wls.

woxi run tests/scripts/hello_world.wls

The interactive REPL is the third, and it keeps definitions and the % and Out[] history across inputs.

woxi repl
# In[1]:= x = 5
# Out[1]= 5
# In[2]:= x^2
# Out[2]= 25

The scripting angle goes further than the CLI suggests. The README's opening example is a script with a shebang line, so a .wls file can be marked executable and run directly by the operating system, which is what turns the interpreter into a scripting tool rather than a REPL toy. The example body uses RandomInteger piped through Map and Print to square five random integers between 1 and 9.

The repository layout backs the claim that this is a multi-surface project rather than a single binary. There is a crates directory, an npm directory, a woxi-py directory, a woxi-studio directory, a jupyterlite-woxi-kernel directory, plus src, tests, benches, fuzz and datasets directories, and an examples directory with a data-analysis example and a notebook.

A kernelspec embedded in the binary, so installation method does not matter

Notebook support is the second half of the target audience, and the mechanism is unusually clean. The kernel is installed with a subcommand.

woxi install-kernel

The reason this works from any directory and with any installation method is that the kernelspec is embedded in the woxi binary itself. The registration logic adapts to what is on the machine: it is registered with jupyter kernelspec install when the jupyter command is available, and written to Jupyter's kernels directory directly otherwise. A --system flag installs it for all users rather than only the current one.

With the kernel in place, the usual Jupyter workflow applies.

cd examples && jupyter lab

For people who do not want to install anything at all, the project hosts a JupyterLite instance that runs fully self-contained in the browser, with no data sent to the cloud. That instance is linked from the README as a way to try the interpreter.

Woxi Studio is the other notebook surface. Every GitHub release ships archives of the woxi CLI and the Woxi Studio notebook editor for Linux, macOS and Windows, on x86-64 and arm64, alongside a SHA256SUMS.txt to verify the archives against. On macOS the editor comes as a Woxi Studio.app bundle that is not notarized, so the quarantine flag has to be removed once after unzipping.

xattr -dr com.apple.quarantine "Woxi Studio.app"

That step is a real operational detail and a fair signal of where the project stands: the archives ship with checksums but the app is not notarized by Apple, and every macOS user removes the quarantine flag by hand.

A language server that warns on symbols the interpreter cannot run

Woxi ships a Language Server Protocol server for the Wolfram Language, started with a subcommand.

woxi lsp

It speaks LSP over stdin and stdout, which is how editors start such a process, and it is meant to be configured for .wl, .wls, .m and .nb files.

The feature that matters most is not the usual hover text. Diagnostics include syntax errors plus warnings on the symbols this interpreter does not implement, so you see what a script will not do before running it. Given that Woxi implements a subset, this is the feature that turns the subset from a limitation into something you can work around at edit time rather than at runtime.

The rest is standard but complete for a small interpreter. Hover documentation and completion are provided for every built-in symbol, and the text comes from the same registry the interpreter uses, so the completions cannot promise a function the engine lacks. Go to definition, find references, occurrence highlighting and the document outline are all computed from the assignments in the file.

The README gives a Neovim configuration as the concrete example, wiring the command to the wolfram filetype with .git as the root marker and then enabling it. The broader point is that the LSP is not a side project: it is the mechanism by which an editor can tell you that a symbol is out of scope before your script fails.

The CLI comparison, and where the approaches diverge

The README includes a table comparing Woxi with WolframScript, and the two columns differ in ways that go beyond syntax.

The overlapping commands are the obvious ones: woxi eval corresponds to wolframscript -code, woxi run script.wls corresponds to wolframscript script.wls, and woxi repl corresponds to running wolframscript with no arguments. The divergence is in the two rows where WolframScript has no counterpart. Woxi can run a .nb file directly with woxi run notebook.nb, and the table notes that WolframScript cannot run .nb files directly. Woxi also ships a language server, which the table marks as not supported for WolframScript.

So the difference in approach is not that Woxi evaluates the same expressions faster. It is that Woxi treats the notebook and the editor as first-class parts of the workflow, while the comparison tool is a script runner. A team that keeps .nb files as the source of truth for analysis gets a toolchain where the notebook is executable from the command line and the file type has hover documentation in the editor.

The other side of the trade is explicit in the project's own framing. Woxi implements a subset, so a script that depends on the wider Wolfram system will not simply run slower, it will not run. The functions.csv file is the place to check, and the language server warnings are the place to find out while editing.

A Cargo workspace whose default build deliberately excludes the editor

The repository is a Cargo workspace with an unusually opinionated member list. The workspace members are the root package, crates/woxi-parser, crates/woxi-reduce, woxi-studio and woxi-py, but the default-members setting is just the root, so the unscoped commands such as cargo build, make test and CI build only the interpreter.

The reason is recorded in the manifest: woxi-studio, built on iced with wgpu and winit, pulls in more than a hundred extra crates, so it is built explicitly through -p woxi-studio or make install-macos-app. The cargo-fuzz crate is excluded from the workspace entirely because it needs nightly plus libFuzzer and must not affect the root Cargo.lock or the default builds. The manifest also pins default-run to woxi so that cargo run -- eval points at the interpreter CLI rather than the woxi-diff-fuzz helper binary, and it sets readme to the lowercase readme.md explicitly so cargo does not synthesise a duplicate uppercase entry in the packaged crate.

Testing is arranged in the same spirit. The test suite runs with make test, and the Dockerfile pins rust:1.91-slim-bookworm so runs are byte-for-byte reproducible across machines, with a comment noting that edition 2024 needs Rust 1.85 and the current cargo-nextest needs Rust 1.91. That image exists to exercise the Linux branches of platform-dependent symbols on hosts that are not Linux.

#   docker build -t woxi-test -f Dockerfile .
#   docker run --rm --hostname woxi-test woxi-test

The makefile also exposes the same path as make test-docker. Between cargo-nextest, a pinned toolchain image and the differential CLI tests against WolframScript, the repository makes a real attempt at reproducibility.

Two releases, an active main branch, and an AGPL-3.0 obligation

The release history is short. v0.2.0 shipped on 2026-07-16 and v0.3.0 on 2026-08-06, and the version in Cargo.toml matches at 0.3.0. Both are pre-1.0, which is consistent with a project whose documented scope is a subset of a language and whose function list is still growing.

The last push was on 2026-10-20, well after the 0.3.0 tag. For a user this means the tagged release and the tip of main are not the same interpreter, and functions.csv on main will list more than the 0.3.0 release implements. If you pin a version, you should read the function list from that tag rather than from the default branch.

The licence is the part that deserves attention before anything else. The repository says AGPL-3.0 and the crate metadata says AGPL-3.0-or-later. That is a copyleft licence with network use provisions, and it is a materially different choice from the permissive licences common in the Rust ecosystem. It is not a legal opinion, but it is a concrete constraint: if you intend to embed the interpreter in a service that users reach over a network, the obligations of AGPL-3.0 apply to that deployment, and that is a decision for your own counsel rather than for a README. The npm package woxi-wasm and the PyPI package woxi are published from the same source, so the same question follows them into JavaScript and Python environments.

Editorial conclusion

Woxi fits engineers who already write Wolfram Language and want a fast local interpreter for scripts, notebook work and editor tooling without a Mathematica licence, and it fits best for the subset the project has actually implemented. It does not fit work that depends on the long tail of Wolfram system functions, and the project is honest about that: functions.csv carries the implementation status of each function, and any script that touches an unimplemented symbol has to change. Verify three things first: that the functions your script needs are marked as implemented in functions.csv, that the differential tests in tests/cli pass on your machine, and that you can accept the AGPL-3.0 licence terms before you embed Woxi in a product.

Frequently asked questions

Official sources

1. ad-si/Woxi on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases