Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a C Compiler, in Zig (2025)

ar-ms.me

Post reply on HN
Print view View original

61–70 of 74 posts

Re: Writing a C Compiler, in Zig (2025)

#61

Post by munificent »

LeFantome wrote: post #34
munificent wrote: post #32

Earlier quoted context omitted.

> I'm not sure why people seem to be under the impression that writing a compiler means that the language the compiler is implemented in should have "low level" features. Performance. You definitely can write a compiler in a high-level language and given the choice I certainly prefer to on my hobby projects. Having a garbage collector makes so many compiler algorithms and data structures easier. But I also accept tha…

Does “low level” translate to performance? Is Rust a “low level” language? Take C#. You can write a compiler in it that is very fast. It gives you explicit control over memory layout of data structures and of course total control over what you wrote to disk. It is certainly not “low level”.

> It gives you explicit control over memory layout of data structures

Some with structs, yes. But overall it doesn't give you much control over where things up in memory once references get involved compared to C, C++, or Rust.

Re: Writing a C Compiler, in Zig (2025)

#62

Post by baranul »

bsder wrote: post #39
munificent wrote: post #32

Earlier quoted context omitted.

> I'm not sure why people seem to be under the impression that writing a compiler means that the language the compiler is implemented in should have "low level" features. Performance. You definitely can write a compiler in a high-level language and given the choice I certainly prefer to on my hobby projects. Having a garbage collector makes so many compiler algorithms and data structures easier. But I also accept tha…

> But I also accept that that choice means there's an upper limit to how fast my compiler will. Don't buy it. A decent OCaml version of a C or Zig compiler would almost certainly not be 10x slower. And it would be significantly easier to parallelize without introducing bugs so it might even be quite a bit faster on big codebases. Actually designing your programming language to be processed quickly (can definitively f…

> I suspect that the author would have gotten a lot further had he been using a GC language and not had to deal with all the low-level issues

Agree, that many people are using languages out of context to what they are actually trying to do. In many cases, using a GC language would be far more productive for them. Though I do think we should distinguish between compiled and interpreted GC languages, as often there is a significant gap in performance, that can be wanted or appreciated.

Re: Writing a C Compiler, in Zig (2025)

#63

Post by baranul »

groos wrote: post #58
cxr wrote: post #38

Earlier quoted context omitted.

This comment started out strong, but then: > Pascal compilers have traditionally been written in Pascal, hardly a language which conjures up a "low level" image. It may be the case that it doesn't conjure up such an image, but Pascal is approximately on the same rung as Zig or D—lower level than Go, higher level than assembly. If folks have a different impression, the problem is just that: their impression.

Pascal, as defined by Wirth, had no "low level" features. E.g., no control over memory allocation other than the language provided new/dispose, no bit operators, clunky strings of fixed size, no access to system calls, no access to assembly, not even any hex or octal constants, all features which a language allowing "low level" access is expected to have (e.g. Ada, Modula-2/3, Oberon, all Pascal-derived languages). T…

Many people seem to forget that Pascal evolved, and Wirth was very involved in that evolution. Wirth (as a consultant) helped create Object Pascal (from Apple), which then influenced Turbo Pascal and Delphi. Modula and Oberon are often referred to as influences on earlier or certain versions of Turbo Pascal (versions 4 to 5.5) as well.

Re: Writing a C Compiler, in Zig (2025)

#64

Post by munificent »

rayneorshine wrote: post #45
munificent wrote: post #32

Earlier quoted context omitted.

> I'm not sure why people seem to be under the impression that writing a compiler means that the language the compiler is implemented in should have "low level" features. Performance. You definitely can write a compiler in a high-level language and given the choice I certainly prefer to on my hobby projects. Having a garbage collector makes so many compiler algorithms and data structures easier. But I also accept tha…

>Having a garbage collector makes so many compiler algorithms and data structures easier. Does it really? Compilers tend to be programs that just appends a bunch of data to lists, hashmaps, queues and trees, processes it, then shuts down. So you can just make append-only data structures and not care too much about freeing stuff. I never worry about memory management when I write compilers in C.

> Compilers tend to be programs that just appends a bunch of data to lists, hashmaps, queues and trees, processes it, then shuts down.

This is true if you're writing a batch mode compiler. But if you're writing a compiler that is integrated into an IDE where it is continuously updating the semantic state based on user edits, there is a whole lot more mutability going on and no clear time when you can free everything.

Re: Writing a C Compiler, in Zig (2025)

#65

Post by bsder »

baranul wrote: post #62
bsder wrote: post #39

Earlier quoted context omitted.

> But I also accept that that choice means there's an upper limit to how fast my compiler will. Don't buy it. A decent OCaml version of a C or Zig compiler would almost certainly not be 10x slower. And it would be significantly easier to parallelize without introducing bugs so it might even be quite a bit faster on big codebases. Actually designing your programming language to be processed quickly (can definitively f…

> I suspect that the author would have gotten a lot further had he been using a GC language and not had to deal with all the low-level issues Agree, that many people are using languages out of context to what they are actually trying to do. In many cases, using a GC language would be far more productive for them. Though I do think we should distinguish between compiled and interpreted GC languages, as often there is…

> Though I do think we should distinguish between compiled and interpreted GC languages, as often there is a significant gap in performance, that can be wanted or appreciated.

Sure, that is tautologically true.

However, I maintain that the original author would have gotten much further even with a pathologically slow Python implementation. In particular, munging all the low-level stuff like linking is going to have full-on libraries that you could pass off the task to. You can then come back and do it yourself later.

For me, reaching a point that helps reinforce my motivation is BY FAR the most relevant consideration for projects. Given the original article, it seems like I'm not alone.

Re: Writing a C Compiler, in Zig (2025)

#66

Post by jibal »

jibal wrote: post #46
dnautics wrote: post #37

Earlier quoted context omitted.

They're just removing the obligate dependency. I'm pretty sure they will keep it around as a first-class supported backend target for compilation.

No, the whole point is to eliminate dependencies that they have to maintain. "not obligate" really doesn't mean anything if it's available as a backend--the obligation is on the Zig developers to keep it working, and they want to eliminate that obligation. And the original question was "how will they reivent the wheel on the man-years of optimization work went into LLVM to their own compiler infrastructure?" -- the a…

To clarify, my statement was based on comments I have seen and heard from Andrew Kelley when discussing this subject. I can't locate those at the moment, but here is https://news.ycombinator.com/item?id=39156426 by mlugg, a primary member of the Zig development team (emphasis added):

"To be clear, we aren't saying it will be easy to reach LLVM's optimization capabilities. That's a very long-term plan, and one which will unfold over a number of years. The ability to use LLVM is probably never going away, because there might always be some things it handles better than Zig's own code generation. However, trying to get there seems a worthy goal; at the very least, we can get our self-hosted codegen backends to a point where they perform relatively well in Debug mode without sacrificing debuggability."

The current interim plan (which I think was developed after the comments that I heard from Andrew, perhaps in recognition of their naivete) is for Zig to generate LLVM binary files that can be passed to a separate LLVM instance as part of the build process. Is that "a first-class supported backend target for compilation"? I suppose it's a matter of semantics, but that certainly won't be the current LLVM backend that does LLVM API calls.

P.S. It may be helpful to read through https://github.com/ziglang/zig/issues/13265

Re: Writing a C Compiler, in Zig (2025)

#67

Post by mlugg »

jibal wrote: post #66
jibal wrote: post #46

Earlier quoted context omitted.

No, the whole point is to eliminate dependencies that they have to maintain. "not obligate" really doesn't mean anything if it's available as a backend--the obligation is on the Zig developers to keep it working, and they want to eliminate that obligation. And the original question was "how will they reivent the wheel on the man-years of optimization work went into LLVM to their own compiler infrastructure?" -- the a…

To clarify, my statement was based on comments I have seen and heard from Andrew Kelley when discussing this subject. I can't locate those at the moment, but here is https://news.ycombinator.com/item?id=39156426 by mlugg, a primary member of the Zig development team (emphasis added): "To be clear, we aren't saying it will be easy to reach LLVM's optimization capabilities. That's a very long-term plan, and one which w…

> The current interim plan...

What do you mean by "interim"? As I explicitly stated in the comment you quoted, it has never, and likely will never, been planned for the Zig compiler to become incapable of using LLVM. The LLVM backend still sees plenty of active development by the core team [0]---that's perfectly compatible with improving the experience of users (including ourselves) by avoiding unnecessary uses of LLVM [1].

> ...is for Zig to generate LLVM binary files that can be passed to a separate LLVM instance as part of the build process. Is that "a first-class supported backend target for compilation"? I suppose it's a matter of semantics, but that certainly won't be the current LLVM backend that does LLVM API calls.

I think you are incorrectly assuming that we currently make heavy use of the LLVM API. As indicated by #13265 being closed, that is not true. The Zig compiler already generates bitcode by itself, without touching the LLVM API. The only thing we actually use the LLVM API for is feeding that bitcode to LLVM, which can easily be done by invoking a CLI instead. Users quite literally would not be able to tell if, for instance, we changed the compiler to pass the bitcode to Zig's embedded build of Clang over CLI.

[0]: https://ziglang.org/devlog/2026/#2026-04-08

[1]: https://ziglang.org/download/0.15.1/release-notes.html#x86-B...

Re: Writing a C Compiler, in Zig (2025)

#68

Post by AndyKelley »

jibal wrote: post #46
dnautics wrote: post #37

Earlier quoted context omitted.

They're just removing the obligate dependency. I'm pretty sure they will keep it around as a first-class supported backend target for compilation.

No, the whole point is to eliminate dependencies that they have to maintain. "not obligate" really doesn't mean anything if it's available as a backend--the obligation is on the Zig developers to keep it working, and they want to eliminate that obligation. And the original question was "how will they reivent the wheel on the man-years of optimization work went into LLVM to their own compiler infrastructure?" -- the a…

First I was naive to believe I could make a new programming language, then I was naive to believe it would be anything but a toy project, then I was naive to believe that we could make our own backends for debug mode, now I'm naive to believe that we can add optimizations to the pipeline. It's getting old. Just because you lack the creativity, willpower, and work ethic to accomplish something, doesn't mean I do.

Re: Writing a C Compiler, in Zig (2025)

#69

Post by jibal »

AndyKelley wrote: post #68
jibal wrote: post #46

Earlier quoted context omitted.

No, the whole point is to eliminate dependencies that they have to maintain. "not obligate" really doesn't mean anything if it's available as a backend--the obligation is on the Zig developers to keep it working, and they want to eliminate that obligation. And the original question was "how will they reivent the wheel on the man-years of optimization work went into LLVM to their own compiler infrastructure?" -- the a…

First I was naive to believe I could make a new programming language, then I was naive to believe it would be anything but a toy project, then I was naive to believe that we could make our own backends for debug mode, now I'm naive to believe that we can add optimizations to the pipeline. It's getting old. Just because you lack the creativity, willpower, and work ethic to accomplish something, doesn't mean I do.

I admire your creativity, willpower, and work ethic, and a few other things about you, but I don't admire reactionary garbage like this ... I'm actually rather shocked by it and how it leans heavily on the strawman "I'm naive to believe that we can add optimizations to the pipeline" which is not the statement that was made, but I will maintain my high regard for you and your efforts despite it ... no human is perfect. I have a lengthy list of technical brilliancies in Zig that I admire that I won't bore you with but do often bore others with.

At least you acknowledge that I am correct about your belief, whereas someone else said I was exactly wrong.

As for me, while I had a successful software development career spanning 6 decades, received a mention in a two-digit RFC, and hold several networking patents, my best years are far behind me, but even in my heyday I couldn't hold a candle to your creativity, willpower, work ethic, or productivity ... but how is that at all relevant?

Re: Writing a C Compiler, in Zig (2025)

#70

Post by DarkUranium »

zamadatix wrote: post #30
Ygg2 wrote: post #19

Earlier quoted context omitted.

> That being said Rust is definitely a much higher level language than either C or Zig. The availability of `Arc` and `Box`, the existence and reliance on `drop` I mean, C++ have RAII and stuff like unique pointer, does that make it higher level than Zig? And what if you don't use Arc or Box? Is your program now lower level than baseline Rust? As I said, depends a lot about what you mean by low level.

I'd say so. Zig is aiming to be a bit smarter than C while staying at roughly the same level. C++ more sought/seeks to support C but offer higher level things with it.

I feel like Zig is to C what Rust is to C++, kind of.
Post reply on HN