buzz is a Zig scripting language with a MIR JIT and an alpha warning

The warning is the first thing in the README

Before the feature list there is a callout that says buzz is in alpha and is not ready for any professional or production use.

That is the author's own assessment, stated without hedging, and it should be the first input to your decision rather than a footnote. An alpha language can be a perfectly good thing to use for a specific purpose. What it cannot be is something you build a business on.

The feature list that follows is short and specific rather than aspirational. Small in size and complexity. Statically typed. Unambiguous. No nonsense coercion.

Those last two are design commitments with consequences. The feature list explicitly lists “No nonsense coercion,” without defining how the rule is implemented.

For a scripting language that is a coherent position. Buzz lists “No nonsense coercion” as a design commitment, although the README does not define its exact behaviour.

The language is written in Zig, and the repository is written in Zig down to its build system, which is what makes the build story a single toolchain.

Building takes four steps and a submodule

The requirements are pinned tightly, which is what you expect from a project built on a young toolchain.

Zig 0.16.0 is the stated requirement, and libc is required alongside it. Supported platforms are Linux, macOS and Windows. The README also notes that because the project is built with Zig you should be able to build on a wide variety of architectures, while being clear that it has only been tested on x86 and M1.

The build sequence is four steps. Clone with `git clone https://github.com/buzz-language/buzz <buzz_dir>`, then check out the submodules with `git submodule update --init`, then build with `zig build -Doptimize=ReleaseSafe`.

The submodule step matters. The repository has a `.gitmodules` file and a `vendors/` directory at the root, which is where the vendored dependencies live, and if you skip that step the JIT dependency will be missing at build time rather than at run time.

After building, you point `BUZZ_PATH` at `./zig-out` and run the result. `buzz` on its own launches the REPL, `buzz <script.buzz>` runs a single script, `buzz <directory>` runs a buzz package, and `buzz init` starts a new package.

Those four invocations are the whole command line surface, and the fact that a directory and a script are both valid arguments tells you packages are a first-class concept rather than a convention.

Install targets a prefix, and the optimize mode is your choice

Installing is the same build command with a prefix, which keeps the whole setup to one toolchain.

# install locally at ~/.local
zig build -Doptimize=ReleaseSafe install -p ~/.local

# install globally at /usr/local
sudo zig build -Doptimize=ReleaseSafe install -p /usr/local

Afterwards the PATH has to include the bin directory of wherever you installed, with an example given as exporting PATH with `/home/xxx/.local/bin` appended.

The optimize flag is the one decision worth making deliberately. The default recipe uses ReleaseSafe, which keeps runtime safety checks while optimising. The README says that if your usage is performance critical, game development for example, you can build with `-Doptimize=ReleaseFast`.

For a JIT-compiled scripting language this is a genuine fork in the road. ReleaseSafe means undefined behaviour is caught rather than silently miscompiled, which matters when the code being compiled was written by someone else. ReleaseFast removes those checks, which is what you want in a game loop and is what you do not want in a tool processing untrusted scripts.

The build files are standard Zig, with `build.zig`, `build.zig.zon` and a `build/` directory, so anyone familiar with a Zig project will find the configuration familiar.

Fibers, and a JIT built on MIR

Two features do the interesting work, and one of them is a third-party dependency worth knowing about.

Fibers are listed as a feature, which is what lets a scripting language have concurrent-looking control flow without threads. For an embedded scripting host, fibers are how you suspend execution and resume it later, and for a language of this size they are the cheapest way to offer an async surface without a runtime.

JIT compilation is the other, and it goes through MIR, a separate project by vnmakarov. MIR is a compiler backend that emits machine code rather than object files. Using it means buzz compiles buzz programs to native code at run time instead of walking a bytecode interpreter, which is the difference between a scripting language you can use for real work and one you use for glue.

The examples directory shows what that buys in practice. There is 2048, game-of-life and voronoi-diagram, which are the graphics exercises every language gets tested against. There is fizzbuzz and fibonacci, which are the parser and control flow exercises.

More telling are the ones with dependencies. The directory also includes `sdl.buzz`, `sdl-wrapped.buzz` and `sqlite.buzz`.

The wrapped and unwrapped pair is the interesting detail, because it tells you the author was deciding how foreign functions should look in the language. A `vendors/` directory and a `build/` directory at the root suggest C libraries are compiled in rather than loaded dynamically, which fits the small-and-simple goal.

Tooling is the strongest part of the feature list

The tooling section is longer than the language feature section, and for an alpha language that is a deliberate choice.

There is a VS Code extension, published in the marketplace. Helix is supported through a tree-sitter grammar in a separate repository. There is an LSP, a DAP, a formatter, and a package manager.

LSP and DAP together are the difference between a language you edit in a plain text file and a language you work in. The README lists both LSP and DAP as tooling features. Shipping both in an alpha is unusual and it says the author is optimising for the experience of someone actually using the language rather than for landing a specification first.

A formatter matters more here than usual. A canonical formatter removes formatting from code review arguments and gives new contributors a way to match style without reading a style guide.

The package manager is what makes `buzz init` and directory execution a workflow rather than a novelty. And the repository has `CHANGELOG.md`, `tests/` and an `examples/` directory, plus a `buzz.code-workspace`, which is a development convenience indicating an editor setup for the language itself.

Release history is short: 0.3.0 on 2023-10-13, 0.4.0 on 2024-05-16 and 0.5.0 on 2025-01-24. The last push was on 2026-08-27, so work continues but releases are infrequent, and the version numbers being low and infrequent is consistent with the alpha label.

The AI policy is a rejection criterion, not a preference

There is a section headed AI policy, and it is the most distinctive thing in the README.

The author points out that the repository has an AGENTS.md file and states clearly that this is not an invitation to submit AI generated code. The distinction drawn is between AI assisted coding, where AI is used as a helper to better understand, debug and improve code, and AI generated code, where the understanding of the author ends at the prompt.

The stated consequence is blunt: blatant slope PRs will be rejected.

This is worth knowing before you contribute, and worth respecting as a norm rather than a preference. A lot of open source projects have an AGENTS.md so that generated contributions at least follow the local conventions. This one has one so that agents know they are not the point.

The licence is MIT, so nothing about the licence prevents AI-assisted work; this is a project culture decision by a single maintainer, and it is their call.

Where buzz is the wrong choice, then, is simple to state. Not for production, which the warning rules out. Not for a language with a large standard library and a large community, since a language at 0.5.0 with a handful of examples has neither. Not if you need threads rather than fibers, or if your platform is not Linux, macOS or Windows with libc.

What it is good for is learning a language designed around a few firm opinions, embedding a small statically typed scripting layer in a host program, or following a Zig project that is small enough to read.

Editorial conclusion

Adopt buzz for learning a statically typed scripting language, for embedding a scripting layer, or for experimenting with MIR as a compilation target, and build it yourself with Zig 0.16.0. Skip it for anything production, which the author states explicitly in a warning at the top of the README. Verify first that `git submodule update --init` succeeded, since the MIR dependency arrives that way, and expect the language surface to change between the 0.x releases.

Frequently asked questions

Official sources

1. buzz-language/buzz on GitHub
2. License: MIT
3. Project website
4. README
5. Releases