I would like to show you what I have been working on over summer and mostly during my evenings after work.
A HOCON parser for Zig: GitHub - lejmr/zig-hocon: HOCON (Human-Optimized Config Object Notation) parser for Zig · GitHub
The whole idea behind it is to have a superior configuration layer for my future applications where json, toml, or yaml can not stand. Speaking about complicated configuration files where you want to reuse configuration sections across multiple environments or configuration variants.
The interface tends to be pretty standard: 1) you define your target structure 2) you load it.
const Server = struct {
host: []const u8,
port: u16 = 8080,
level: enum { debug, info } = .info,
};
const parsed = try hocon.parseFromSlice(Server, gpa,
\\host = example.org
\\level = debug
);
defer parsed.deinit();
It’s early. Parsing, dotted keys, merging, concatenation and conversion into
structs work; includes and substitutions don’t yet, so most real
application.conf files won’t load today.
Important part of the repo is conformance suite which turns specification into data points. I kept arguing with myself about what HOCON.md actually says, so I turned it into a test suite. Reference is obviously lightbench/config which I am checkinng against + HOCON.md specification. Current state of the art against the conformance suite gives:
| vs spec | vs typesafe/config | |
|---|---|---|
| typesafe/config 1.4.9 | 89% | 99% |
| pyhocon 0.3.63 | 71% | 67% |
| zig-hocon | 57% | 59% |
The Java one surprised me — it disagrees with its own spec in 43 places, and
some of those I’ve been sending as PRs to lightbend/config. The suite is plain
data, so any HOCON parser can be plugged in with a small adapter.
I’d love to hear whether mirroring std.json feels right to you, and what you use for config in Zig today.
Do you need zon interface?
Supported Zig versions
0.16.0.
AI / LLM usage disclosure
The parser itself — tokenizer, parser, value graph, conversion and the public
API — is written by hand; learning Zig was the point. I used Claude for the
tooling around it: the oracle wrappers, the conformance runner and report
generator, and drafting part of the conformance cases. Expected values never
come from a model — they come from running typesafe/config and are then checked
by hand against the spec text. Claude also helped me edit the README, and a lot of other boring parts.