Zen C: a C11 transpiler with generics, traits and async/await

What Zen C solves, and for whom

Zen C is a compiler, not a runtime. The README describes it as "a modern systems programming language that compiles to human-readable `GNU C`/`C11`", and the tagline in the same file is "Write like a high-level language, run like C." So the audience is narrower than the tagline suggests: people who are already committed to C, or who must be, and who want generics, pattern matching, traits, async/await and type inference in the source they maintain.

The pitch rests on one property that most transpilers give up: the output is meant to be read. If the generated C is legible, you can inspect it, hand it to a C debugger, and mix it with existing C translation units. That is the difference between Zen C and a language that merely happens to have a C backend.

The repository also claims 100% C ABI compatibility, which is the claim that matters for adoption. It means calling into an existing C library is not a foreign function interface problem. It also means the reverse: a C project can consume a Zen C object file without a shim. That is the whole reason a team would accept a second language in a C codebase.

The mechanism: source in, GNU C out

The repository layout confirms the architecture. There is a src/ directory holding the compiler, a std/ directory holding the standard library, a std.zc entry point, a man/ directory, plugins/, fuzz/, tests/, and an ape/ directory for the portable build. The compiler is written in C, per the repository's primary language. There is no virtual machine directory, no bytecode format, no JIT directory. The pipeline is source to C to native object code, with the system C compiler doing the final step.

That has a consequence worth stating plainly: your C compiler is part of your Zen C toolchain. The Makefile probes for `-std=gnu23` and falls back to `gnu11` with a warning if the compiler rejects it, and it probes separately for `constexpr` support, defining `HAS_CONSTEXPR` only when the probe compiles. It also special-cases tcc, which "does not support -MMD -MP, may not search /usr/local/include, and maxes out at C11", and forces `gnu11` in that case. So the quality of your generated code depends on which C compiler you point it at. The project documents gcc as the default, clang and `zig cc` as alternatives, and tcc as a constrained option.

The standard library is written in Zen C itself, living under std/ and imported with paths like `import "std/vec.zc"`. The `ZC_ROOT` environment variable tells the compiler where that tree lives, which is what lets you run `zc` from any directory rather than only from the checkout.

Installing Zen C from source and compiling a first file

The README's Quick Start gives a source build with make. Clone, clean, build, install. The install step needs root because the default share directory is `/usr/local/share/zenc`, which is where the standard library lands.

git clone https://github.com/zenc-lang/zenc.git
cd zenc
make clean
make
sudo make install

If you are not installing system-wide, or you want to run the compiler straight out of the checkout, set `ZC_ROOT` to the repository root. The README gives this exact form:

export ZC_ROOT=/path/to/Zen-C

With that set, standard imports such as `import "std/vec.zc"` resolve regardless of your working directory. Once the compiler is on your PATH, the documented entry points are `zc run` for a compile-and-execute cycle and `zc build` for producing a binary with an explicit output name:

zc run hello.zc
zc build hello.zc -o hello

The README does not show the contents of `hello.zc`, so the first thing to write is your own minimal file. The repository ships a `zc-repl` binary for an interactive shell and `zc-doc` for generating documentation, with a recursive default and a `--no-recursive-doc` flag for single-file runs. On Windows the documented path is `build.bat` with GCC via MinGW, producing `zc.exe`; the README states that networking, filesystem and process operations are supported through a Platform Abstraction Layer, and that make works under MSYS2, Cygwin or git-bash.

The portable binary and what it actually buys you

The most unusual target in the Makefile is the Actually Portable Executable build, which uses Cosmopolitan Libc. The README states that `make ape` produces a single `.com` binary that runs natively on Linux, macOS, Windows, FreeBSD, OpenBSD and NetBSD on both x86_64 and aarch64. It requires the `cosmocc` toolchain to be on your PATH.

make ape
sudo env "PATH=$PATH" make install-ape

Two artifacts come out of this. `out/bin/zc.com` is the portable compiler with the standard library embedded inside the executable, and `out/bin/zc-boot.com` is described as a self-contained bootstrap installer for setting up new Zen C projects. The documented invocation is `./out/bin/zc.com build hello.zc -o hello`.

The embedding is the interesting part. A normal install depends on `ZC_ROOT` or on the compiled-in `ZEN_SHARE_DIR`, which the Makefile sets to `/usr/local/share/zenc` by default. The APE build removes that dependency by carrying the standard library with it, which is why the `sudo env "PATH=$PATH"` form appears: the install target needs the cosmocc path preserved across the privilege boundary. That is a real constraint on the command, not a stylistic choice.

Where Zen C is the wrong tool

The README does not document rollback, and it does not describe a stability guarantee for the language surface. The release cadence visible in the repository is three releases in roughly a month, v0.4.2 through v0.4.4, all in the 0.4 line. A 0.4 language is a moving target, and because the standard library is written in Zen C and imported by path, a standard library change is a source-level break for consumers. There is no documented versioning policy for `std/` in the README.

The second limitation is toolchain coupling. The Makefile's probes show the compiler adapting to what the C compiler supports rather than pinning a standard. If your environment has an older GCC, you get the `gnu11` fallback and a warning, and the feature set of the generated code changes accordingly. The tcc path is explicitly degraded. Anyone who needs byte-identical output across machines should test that assumption rather than assume it.

The third is Windows. The documented native path is `build.bat` with MinGW, and the alternative is a Unix-like environment. There is no documented MSVC path. If your team builds on Windows with MSVC, this is not the project for you yet.

Finally, the VS Code extension is listed in the ecosystem table with the status Alpha, while the core compiler is listed as Active Development. Editor support lagging the compiler is normal at this stage, but it means the LSP experience is the least settled part of the toolchain.

How Zen C differs from Zig and C3

The obvious comparison is Zig, and the difference is not the feature list. Zig is a compiler toolchain that owns its own backend pipeline and ships `zig cc` as a C compiler. Zen C does not replace your C compiler; it feeds it. The Makefile even documents `make CC="zig cc"` as a build option, which means you can use Zig's C compiler to build Zen C itself. That is a different relationship from competing with Zig.

The practical difference shows up in the output. A Zig build produces a binary; a Zen C build produces C and then a binary, and the intermediate C is intended to be inspected. That matters if you need to audit what your abstractions cost, or if you have to hand a translation unit to a downstream team that will never install `zc`.

C3 is the closer comparison in spirit, since both aim to be a modern language with C interop. The distinction the Zen C README draws is the transpilation target: GNU C and C11, described as human-readable, with the 100% C ABI compatibility claim attached. Whether that matters depends on whether you want a new compiler toolchain or a new source language that reuses the one you already have. Zen C is squarely the second.

Licence, maintenance and upgrade cost

Zen C is MIT licensed, per the repository's licence field and the badge in the README. The repository also contains a LICENSES/ directory alongside the top-level LICENSE file, which suggests bundled third-party components carry their own terms. The README does not enumerate them, so if you vendor the compiler or the standard library into a product, read that directory rather than assuming a single licence covers everything. That is a fact about the repository layout, not legal advice.

On maintenance: the last push to the repository was on 2026-08-13, and the most recent tagged release is v0.4.4 from 2026-03-20. The repository is not archived. The gap between the last release and the last push is worth noting if you are pinning to a tag rather than tracking `main`.

The upgrade cost is concentrated in two places. First, the standard library, because it is imported by source path and written in the language itself. Second, the generated C, because the compiler's C standard target can shift with your environment. The Makefile exposes `make C_STD=gnu11` as a documented override, which is the lever to pull if a newer default breaks your build. There is also a `make WERROR=1` target for treating warnings as errors, and the Makefile sets `WERROR ?= 1` by default, so a warning in your generated code can fail the build unless you override it.

Editorial conclusion

Adopt Zen C if you already ship C and want type inference, pattern matching, generics, traits and async/await without giving up the C ABI or readable generated code. Skip it if you need a stable language specification, a Windows build without MinGW or MSYS2, or a package manager install. Before committing, verify that your target compiler works with the default gnu23 setting, that ZC_ROOT resolves your standard imports, and that the generated C is something you are willing to debug by hand.

Frequently asked questions

Official sources

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