--- title: Inside Zig's Incremental Compilation | daily.dev description: A deep technical walkthrough of how Zig's incremental compilation works, written by a Zig core team member. Covers the full compiler pipeline: per-file ZIR... canonical: https://daily.dev/posts/inside-zig-s-incremental-compilation-q4hsf5zcw twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Inside Zig's Incremental Compilation | daily.dev og:description: A deep technical walkthrough of how Zig's incremental compilation works, written by a Zig core team member. Covers the full compiler pipeline: per-file ZIR... og:url: https://daily.dev/posts/inside-zig-s-incremental-compilation-q4hsf5zcw og:image: https://api.daily.dev/og/posts/Q4hSF5zCW.png og:image:alt: Inside Zig's Incremental Compilation og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Inside Zig's Incremental Compilation **[Lobsters](https://daily.dev/sources/lobsters)** · 27 min read · 2 upvotes · 0 comments ## Summary A deep technical walkthrough of how Zig's incremental compilation works, written by a Zig core team member. Covers the full compiler pipeline: per-file ZIR caching (embarrassingly parallel, near-instant), semantic analysis with a dependency graph tracking which declarations need re-analysis when source changes, code generation (also parallel, per-function), and incremental linking via a MappedFile abstraction that patches only changed bytes into the output binary. Real-world demo shows rebuilds completing in 50–70ms. Currently works on x86_64-linux with Zig master branch using `zig build --watch -fincremental`. Known limitation: a graph traversal during flush currently takes ~30ms even when unchanged, identified as a clear optimization target. The feature is functional but not yet stable. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 2 discussions and 64 comments across hackernews, lobsters (as of 2026-07-28). **TL;DR:** The community is broadly impressed by Zig's incremental compilation work, while a lengthy side-debate dominates the thread about whether memory safety (as Rust defines it) is truly 'table stakes' versus a point on a spectrum of tradeoffs. **Sentiment:** 45% positive · 35% mixed · 20% skeptical **The case for** - Zig's language design was deliberately tweaked to make incremental compilation easier, which pays off significantly. - The self-hosted backends enable fast debug-build iteration without LLVM dependency. - Zig's explicitness ('no hidden behavior') may make it easier to port code to other languages like Rust later. **The pushback** - Incremental compilation currently only works with debug builds and Zig's own backends, not LLVM/release builds. - Some optimizations (e.g., inlining) are fundamentally incompatible with incremental compilation, limiting future release-build applicability. - Rust's proc macros are impure and must be re-expanded every incremental build, a structural obstacle Rust faces. - The design of patching a single large binary raises questions about corruption risk and whether shared-library-per-module would be simpler. **By community** - hackernews (mixed): Enthusiastic about Zig's toolchain progress but dominated by a heated philosophical debate between steveklabnik and pron over whether memory safety is 'table stakes,' with additional technical threads on Rust compile times and fil-c. - lobsters (mixed): No comments available to assess sentiment. **Hottest debate:** Whether memory safety (in the Rust/Java sense of a clear safe/unsafe delineation) constitutes universal 'table stakes' or is merely one point on a continuous spectrum of tradeoffs, with pron and steveklabnik going multiple rounds. **Open questions** - Will Zig's incremental compilation ever extend meaningfully to release/optimized builds? - How will C source compilation be handled incrementally once the LLVM hard dependency is removed? - What happens to the incrementally-patched binary if compilation is interrupted mid-patch? **Highlights** > It only works with our self-hosted code generation backends (the main one being for x86_64), which right now don't have any optimisation passes. It's planned that they will in future, but that's a long-term goal. Also, any optimisations which propagate information between functions (the most obvious and important one is inlining) are more-or-less incompatible with incremental compilation (I touch on this in the post IIRC), so once this does work it'll probably still be limited to a subset of optimisations. TL;DR: only debug builds for now, could extend to release builds once we have our own optimisation passes one day, but some optimisations will still be inapplicable. > — [mlugg on hackernews](https://news.ycombinator.com/item?id=49086793) > Macros can be, but in part because they can produce new items (top level declarations, to sort of make the same handwave as the article does) and so that means you have to do macro expansion and stuff before you can even start to check some things, and similar issues. See the link I posted above for some details on a related issue. There's also stuff around name resolution. Proc macros are just an inherently very slow way to do what they do. Because Rust commits to the traditional compilation model and pipleine (which I think is overall a good thing, or at least, a good thing to support), it does a lot of work that will eventually be thrown away. Consider this example: I have a library with a function foo that returns a simple 42. I have a binary which calls foo from that library and prints the result. Now imagine the library is a hundred thousand lines of unrelated code to what the binary needs, but is useful for other people. Because compilation works in the "produce libraries, produce binary, link them all together" style model, you have to compile the entire library with all of that code, when all you need is really one function. That intermediate work is useful, and I'm picking an example that's deliberately extreme, of course. There's a bunch of stuff like this, and I do not have time to really say more than that right now. But yeah, monomorphized generics also produce a lot of compile time pressure too, in various ways. Anyway I just also want to reiterate a few things: first of all, all of these decisions were made for good reasons, and there are pros to what Rust does and why. It's just that compile times suffer because of it. What I wish was that we had taken compile times into more consideration when deciding what to do and why in a more serious way. The same decisions might have been made, but at least it would have been known, rather than the situation now, where there's just a tremendous amount of work to try to optimize what exists, rather than having the freedom to maybe tweak some things to make that job way easier. > — [steveklabnik on hackernews · 1 comments](https://news.ycombinator.com/item?id=49087153) > Okay so: in general, as a rule of thumb: anything that makes stuff have more memory safety is good. And experiments towards that end are also good. What I do not like, primarily comes down to how the project is talked about and marketed. First, because it promotes an "us vs them" mindset, instead of a "we're all trying to improve memory safety" mindset, and second, because in doing so, it also overstates its case. These things are sort of intertwined. Let's talk about the overstatement first. Fil-c has its own definition of memory safety that is slightly different than others. For example, I saw this recently: #include #include #include struct User { char name[8]; int is_root; }; int main(int argc, char*argv[]) { struct User* user = malloc(sizeof(struct User)); strcpy(user->name, argv[1]); if (user->is_root) { printf("I am root!\n"); } else { printf("I am not root :(\n"); } return 0; } This, when invoked with "012345678" passed in, will print "I am root!". In my understanding, this is deliberately allowed. But beyond corners like this, fil-c's author will go on about "Rust has unsafe as a hatch, fil-c does not" while if you control-f for "zunsafe_" on https://fil-c.org/stdfil you get ... escape hatches. The author regularly erases the difference between "traps at runtime" and "is prevented at compile time", which are legitimate tradeoffs where one or the other may be better depending on what you're doing. But they're presented as either equivalent, or one is superior, and I find this muddles the discourse. The performance issues also tie into this, "add a GC" is absolutely a valid way to handle these sorts of issues, but it is not the same thing as what Rust does. And that's okay! But presenting it as purely superior means that it's just hard to talk about. Speaking of muddling the discourse, the author regularly trolls on X, providing tons of bad faith arguments and generally trying to rile up a "fil-c vs Rust" war that I think reduces our ability to talk about these differences in a calm, engineering focused context. Finally, due to its design, fil-c is effectively Linux only. That's great for Linux, but many people also use other systems, and so it is not a meaningful option for them. Anyway, after saying all that: I still think that it is a good project, and that it should exist and continue to be worked on. I just wish that the heat was turned down, and people could talk about the various approaches and their tradeoffs without turning it into a culture war. > — [steveklabnik on hackernews · 2 comments](https://news.ycombinator.com/item?id=49087952) > > Rust and Java both don't have much problem with unsafety, whereas C does, and at least from what I've heard, Zig does as well. I'm not interested in the definition so much as I am in calling it "table stakes", and so the fact that these languages satisfy their promises is uninteresting in isolation. What matters is the value of their promises. The majority of Rust programs I see, I wouldn't have written in a low-level language, so the fact that it offers memory safety for the things I don't need it to do does nothing for me. Now, clearly, Rust's originators didn't consider what Java offers (or at least what it offered 20 years ago when Rust was first conceived) to be table stakes or they wouldn't have wanted Rust. Java exacted some price in exchange for its memory safety that was unacceptable to Rust's originators and trumped its memory safety. But the same thing happens with Rust vs Zig. Rust exacts a heavy price for its memory safety, that - just as in Rust's case vs Java - is sometimes unacceptable. So I can't see how any of these could be "table stakes". > I mean, sure, if you want to do things that are fundamentally not possible to validate because you think you're smart enough not to screw up, that's going to make Rust a tough sell. What Rust can validate and what can fundamentally be validated are two very, very different things. Compared to what ATS can validate, what Rust can validate is almost indistinguishable from C. In Rust you have to do lots and lots of things that require you to be "smart enough not to screw up" that you could prove in ATS, and still no one (including Rust programmers) would say that what ATS offers is "table stakes" because, obviously, it comes at a high price that the people who choose Rust don't want to pay. So clearly different languages offer different capabilities and charge a price for them. Sometimes the price is worth it and sometimes it isn't. > so I'm distrustful of the claim that being smart and diligent is enough to prevent the sort of bugs that we're still dealing with after half a century of us learning how not to write C But Java or Rust programs still suffer from a lot of bugs that ATS could eliminate, if you're willing to pay the price, and you're clearly unwilling. ATS programmers could say about Rust programmers what you say about C++ programmers. Clearly there's no universal table stakes here. > — [pron on hackernews · 1 comments](https://news.ycombinator.com/item?id=49087959) > There is something that I don't fully understand about this design: why are they insisting on building a giant binary for debug builds that contains all of the code? From my perspective, a simpler approach is to generate many smaller shared libraries (perhaps at the file level) and link them in to the final binary. With this approach, the program binary would have a tiny text section and a (potentially long) list of shared libraries to load. But even with thousands of shared libraries to load, the resulting program binary would not be all that long and there would be no need for binary patching. I understand that for a release mode a single giant binary may be desirable, but I am struggling to understand this design for debug builds. Moreover, while reading this article, I found myself wondering what happens if the main binary becomes corrupted. Maybe the user cancels compilation with ctrl+c while it is patching the binary. Even if they have a story for avoiding and/or detecting corruption, it is simpler to not patch in the first place and always generate a new main binary. Again, this is reasonable because the new binary is mainly just a list of shared libraries to link which will not take up much space and can be written to disk quickly. Moreover, this process can be done recursively, e.g. at the subdirectory level, so that during incremental linking a few quite small shared libraries may be produced rather than patching in the new code and writing cascading relocations. > — [thefaux on hackernews · 2 comments](https://news.ycombinator.com/item?id=49087883) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49085666) · 49 points · 64 comments - [lobsters](https://lobste.rs/s/rmzzdb/inside_zig_s_incremental_compilation) · 1 points · 0 comments ## Similar posts on daily.dev - [Zig Builds Are Getting Faster](https://daily.dev/posts/zig-builds-are-getting-faster-tgeijfdst) · Mitchell Hashimoto · 16 upvotes · 1 comments - [How Our Rust-to-Zig Rewrite is Going](https://daily.dev/posts/how-our-rust-to-zig-rewrite-is-going-kvdc7iim2) · Lobsters · 5 upvotes · 1 comments - [Against Query Based Compilers](https://daily.dev/posts/against-query-based-compilers-wfnhfc9q8) · matklad · 4 upvotes · 0 comments --- Tags: [#zig](https://daily.dev/tags/zig) [View this post on daily.dev](https://daily.dev/posts/inside-zig-s-incremental-compilation-q4hsf5zcw) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Inside Zig's Incremental Compilation","url":"https://daily.dev/posts/inside-zig-s-incremental-compilation-q4hsf5zcw","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/inside-zig-s-incremental-compilation-q4hsf5zcw"},"datePublished":"2026-07-28T16:11:53.984Z","dateModified":"2026-07-28T19:01:29.456Z","description":"A deep technical walkthrough of how Zig's incremental compilation works, written by a Zig core team member. Covers the full compiler pipeline: per-file ZIR...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3fe96cf1ca45536168f6539e2778add6?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3fe96cf1ca45536168f6539e2778add6?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/inside-zig-s-incremental-compilation-q4hsf5zcw","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"zig","timeRequired":"PT27M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Inside Zig's Incremental Compilation"}]} ```