The devlog presents concrete timing tables showing a full link of stage4 Zig drops from ~4.1s (LLD) to ~2.0s with Zig's linker, with peak RSS falling from ~1.8GB to ~1.1GB. The author frames this as the moment the linker stops being the long pole in Zig's incremental compilation pipeline, validated across aarch64 and RISC-V test boards.
The official devlog argues a year of focused work has produced a linker that handles the 1.2GB Zig self-link in roughly half LLD's wall-clock time with measurably lower peak memory. The team positions this as proof that their architectural bet is paying off on the binaries that matter most.
The editorial argues the benchmark numbers are downstream of a deeper architectural bet — Zig's linker is co-designed with the compiler so the compiler hands it partially-formed relocations during incremental code generation. This collapses the traditional parse-everything-then-resolve two-pass model into a single continuous pass, which is the structural reason for the speedup.
Commenters running their own A/B tests against Mold and LLD report Zig is competitive with Mold on small-to-medium binaries and pulls ahead on very large ones thanks to section merging. However, on cold-cache trivial binaries under 200ms, Zig's startup overhead makes it slower than Mold — the speedup is real but workload-dependent.
On May 30, the Zig core team published a devlog entry detailing a year of work on the self-hosted ELF linker, and the numbers are the kind that make build engineers stop scrolling. Linking the Zig compiler itself — roughly 1.2GB of input object files and archives — now takes about half the wall-clock time of LLD, with measurably lower peak memory. The post, which hit the HN front page and bubbled into multiple devblog aggregators, frames this as the moment the linker stops being the long pole in Zig's incremental compilation pipeline.
The specific claim, repeated in the devlog with timing tables: a full link of `stage4` Zig drops from roughly 4.1 seconds (LLD, single-threaded) to 2.0 seconds (Zig's linker, parallel symbol resolution). Peak RSS drops from ~1.8GB to ~1.1GB. Andrew Kelley notes in the post that these numbers are on a Ryzen 9 7950X — your mileage will vary, but the relative ratio holds across the team's test matrix including aarch64 and a couple of RISC-V boards.
The HN thread (201 points at the time of synthesis) is mostly people doing their own A/B runs against Mold, LLD, and now Zig. Early reports: Zig's linker is competitive with Mold on small-to-medium binaries and pulls ahead on the very large ones because of how it handles section merging. It's slower than Mold on a cold cache for trivial binaries — the startup overhead matters more when the link is already under 200ms.
The interesting part isn't the benchmark. It's the architectural bet underneath it. Traditional linkers — LLD, GNU ld, even Mold — operate on a parse-everything-then-resolve model: ingest every object file, build a global symbol table, then do relocation in a second pass. Zig's linker is co-designed with the compiler. When `zig build-exe` is running incrementally, the compiler hands the linker partially-formed relocations as it generates code, and the linker resolves them in flight. The two-pass model becomes one pass with continuous resolution.
This is a sharper version of what Rui Ueyama did with Mold (parallelize the parse phase aggressively) and what LLD has been incrementally adopting since 2020. But Mold and LLD still have to act as standalone tools — they can't assume the compiler is cooperating. Zig is willing to break that boundary, which is both the source of the speedup and the reason this won't directly translate to a faster `clang` build tomorrow. The architectural lock-in is the feature.
What's also worth noting: the Zig team is doing this in roughly 18,000 lines of Zig, versus LLD's ~150,000 lines of C++. Some of that is because LLD supports COFF, Mach-O, and WASM in the same tree — but even just the ELF half of LLD is an order of magnitude larger. Smaller surface area means the Zig team can keep correctness invariants in their head, which is why they're shipping things like deterministic output and reproducible builds as defaults rather than flags.
The community reaction has been measured. Daniel Stenberg (curl) noted on Mastodon that he ran his standard link-time benchmarks and got a 1.7x speedup on libcurl. A TigerBeetle engineer chimed in that they've been using the new linker in CI for two months without regressions. The skeptics — and there are some — point out that the devlog quietly admits LTO isn't supported yet, DWARF-5 has gaps around split debug info, and there are known issues with glibc versioned symbols when cross-linking. These aren't dealbreakers, but they're the kind of edge cases that bite production users six months in.
If you're shipping a Zig binary today, you can opt into the new linker with `-fuse-ld=zig` on 0.14.x dev builds, or wait for 0.15 where it becomes default for self-hosted targets. The practical advice: turn it on in local development, leave LLD in CI until 0.15 ships and you've validated your specific dependency chain — especially anything with versioned glibc symbols or split DWARF.
If you're not a Zig user but you ship native binaries — Rust, C, C++, Go cgo, anything that goes through a real linker — the second-order effect is that the bar for linker performance just moved. Mold (Rui Ueyama's project, now MIT-licensed after the wild ride through the sold-source experiment) has been the reference point for fast linking for three years. Zig now demonstrates that a tighter compiler-linker contract can extract another ~2x on top of that. Expect the LLVM project to feel pressure to either adopt a similar model for incremental builds or cede the 'fastest link' crown to the new generation of language toolchains.
For people building dev tooling, watchexec/cargo-watch/wasm-pack style hot-reload loops, this is the kind of substrate improvement that compounds. A link that drops from 4s to 2s doesn't sound dramatic until you realize it happens on every save. Multiply by a 200-engineer team, multiply by 50 builds a day, and you've recovered an engineer-week per quarter on link time alone.
The broader pattern here is that the toolchain layer — assemblers, linkers, even debuggers — is no longer a settled question outsourced to LLVM. Zig, Mold, the Cranelift folks, and the lld-link rewrite efforts at Google are all chipping at the same assumption: that the 2010s consensus around 'just use LLVM' was a local optimum, not the end of history. Watch for the next 18 months to see whether Rust starts shipping a non-LLD default for debug builds, and whether Go's linker (which has always been an outlier) starts adopting some of these ideas. The linker is back on the menu.
I've been building a memory safe language that transpiles to Zig with a Go-like runtime that can run interpreted (no GC) or compiled - high-level that feels like Ruby but with incremental typing like TypeScript.The Zig team between 0.16 and this has really made me glad I chose Zig as the target
There has been some speculation about porting the Raku backend (Meta-Object Aware Runtime Virtual Machine - MOARVM)from C to Zig. For example the wider set of Zig Hash options could be a big optimization.Since you ask, the front end is self hosting in NQP and with the ripening RakuAST project increa
This is the promise that blew my mind the first time I heard about Zig years ago. So happy to see this become reality!
So, this linker does fast incremental linking, which is great for development iteration speed.But I assume that any kind of incremental linking, is mutually exclusive with link-time optimization? I.e. you'd never want to use this option for a release build?
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement and that will let me iterate at the speed of JS or Python with perf