The Zig devlog frames the ELF linker as toolchain-agnostic: bit-for-bit compatible output with GNU ld and LLD across DWARF, TLS, IFUNC, and --gc-sections, and directly invocable via `rustc -C linker=zig`. The position is that the hard correctness work is already done, so adoption by Rust users is a configuration flag away rather than a research project.
The official devlog presents the linker as having cleared the practical compatibility bar — relocations across thousands of object files, lazy symbol resolution, and linker scripts all working — which is precisely the workload profile of a Rust release build. The implicit argument is that the linker has graduated from Zig-internal infrastructure to a general-purpose ELF linker.
The editorial argues that LLD and mold both descend from Rui Ueyama's phase-based parallel model and have squeezed most of the gains out of that approach — mold over LLD is only 1.5–2x on typical Rust workloads. Zig's linker matters because Andrew Kelley's team rebuilt the model from scratch rather than inheriting that lineage, which is why halving LLD's wall-clock on a 1.2GB self-link is plausible rather than marketing.
The editorial pushes back on dismissing the headline number as a synthetic benchmark. A 1.2GB binary built from thousands of small object files with heavy monomorphization and deep dependency graphs is structurally identical to a Rust release build, so the ~2x speedup over LLD is a credible projection rather than a best-case cherry-pick.
The May 30, 2026 Zig devlog landed with a section on ELF linker improvements that, on the surface, reads like more incremental compiler news. The headline most people will repeat is that Zig's self-hosted linker links the Zig compiler itself — a 1.2GB binary — in roughly half the wall-clock time of LLD. That number is real, and it's already been chewed over on Hacker News (220 points and climbing).
The part that didn't get airtime: this linker is no longer just a Zig-internal tool. The same binary that links `zig build` can now be invoked by `rustc` via `-C linker=zig`, dropping into the toolchain in the same slot LLD or mold occupy today. The devlog confirms the ELF output is bit-for-bit compatible with what GNU ld and LLD emit for the common cases, including DWARF debug info, TLS, IFUNC resolution, and `--gc-sections`. The hard parts — relocations across thousands of object files, lazy symbol resolution, linker scripts — are working, not promised.
The immediate practitioner question is whether this is a curiosity or a real tool. The benchmark Zig published — Zig compiler self-link — is a worst case for most linkers: many thousands of small object files, heavy template-style monomorphization producing duplicate symbols, deep dependency graphs. That's the workload a Rust release build looks like.
The LLVM linker story has been stuck for a while. LLD is fast because Rui Ueyama rewrote it in 2017 to be embarrassingly parallel; mold is faster because Rui Ueyama then rewrote *that* in 2021 with better data structures. Both treat the linker as a sequence of well-understood phases — parse, resolve, relocate, emit — and pour engineering into each. The marginal gains have been getting thinner. Mold over LLD is maybe 1.5–2x on a typical Rust workload; the next 2x is hard to see in that lineage.
Zig's linker is interesting because it didn't inherit the lineage. Andrew Kelley and the linker team rebuilt the model from scratch: incremental linking is a first-class concept, not bolted on; the symbol table is laid out for cache locality from day one; and — critically — the linker is part of the same process as the compiler, so symbol resolution can happen in parallel with code generation rather than after it. For `zig build`, that pipeline integration is where the real win lives. For Rust, you don't get that integration, but you do get the linker's internal architecture, which is still meaningfully faster than LLD on object-file-heavy workloads.
The Hacker News thread surfaced the usual skepticism — "benchmarks are cherry-picked," "wait until it handles weird linker scripts," "come back when it does LTO." Fair points. But the devlog is unusually candid about the failure modes: LTO is explicitly not supported yet, exotic linker scripts (think kernel and embedded targets) will fall back to LLD, and the Windows COFF and Mach-O backends are months behind the ELF one. This isn't a "replace your toolchain" announcement. It's a "if your build is in the 80% case, this is now an option" announcement.
The community reaction worth quoting comes from a longtime mold contributor on HN: "The Zig linker is doing something different. Mold is faster LLD. Zig is what you'd build if LLD didn't exist." That captures the architectural fork. LLD is what you get when you take ld and ask "how do we parallelize this." Zig's linker is what you get when you ask "what would a linker look like if we wrote it in 2024 for a compiler that's also being written in 2024."
Worth naming the elephant: the Rust project has been quietly de-LLVM-ing in pieces — Cranelift as an alternative backend, rustc_codegen_gcc for GCC integration, and now external pressure on the linker slot. None of these are about killing LLVM. They're about not having LLVM be the only option when LLVM is the bottleneck. Link time is, for many large Rust crates, the single largest phase of `cargo build --release`.
If you're shipping a Rust binary with more than 50 dependencies and your release build spends more than 30 seconds in the link step, this is a benchmark worth running this week. The invocation is one line in `.cargo/config.toml`:
``` [target.x86_64-unknown-linux-gnu] linker = "zig" rustflags = ["-C", "link-arg=ld"] ```
You need a Zig 0.15+ binary on the path. The devlog notes that for the linker-only use case, you can pull `zig` from the standard distribution — no separate package. The realistic expectation is a 1.3–1.8x speedup on the link step versus LLD on a debug build, and 1.2–1.5x on a release build where LTO dominates. Mold users will see less benefit; if you're already on mold, the marginal gain is small enough that the toolchain churn isn't worth it.
The place this matters most is CI. A monorepo Rust workspace that links 30 binaries per CI run can shave real minutes off every pipeline. At the team scale, that's developer time you reclaim every push. It also matters for incremental local builds where the link step is the entire latency — anyone who's stared at the "Linking…" line in `cargo build` while editing a single file knows the feeling.
Where this doesn't matter yet: Windows, macOS, anything using LTO, anything with custom linker scripts, anything that depends on plugins in the LLD plugin API. The non-ELF backends are coming, but they're not here. Treat this as a Linux release for now.
The interesting question for the next six months is whether the Rust project tier-promotes Zig's linker — moves it from "works if you configure it" to "available as a documented alternative" in the same way mold currently is. If that happens, you're going to see the LLVM toolchain monoculture in Rust quietly fracture, which is healthy: competition on the linker slot is the first time in a decade anyone has had real leverage to push LLD forward. The deeper signal is that compilers and linkers are starting to be re-thought together rather than as separate components linked by a 1990s ABI. Zig is the first project shipping that integration to a non-Zig audience. It probably won't be the last.
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