1. 106
  1. 15

    Fantastic. Linkers are the worst part of modern compilation stack, still stuck in the 70s. I hope this will evolve beyond just a trick for a debug mode, and we’ll eventually get linkers as smart and helpful as modern compilers have become.

    1. 3

      Incremental linking, or runtime patching, are pretty incompatible with full optimization. They use extra indirection between symbols, which adds overhead. More importantly they don’t allow for link-time optimization, which needs to look at the whole program at once, so a change in one place (alike in a function that gets inclined) might ripple through a lot of the binary.

      1. 10

        I had in mind moving linking into compiles in general. LTO already requires having a full compiler inside the linker, so why not do it the other way, and have the compiler be the linker? No need for fragile order-dependent command-line flags and writing archive files back and forth. Modern compilers give super useful error messages, while linkers “symbol not found, and your mother was a hamster!”

      2. 1

        Yes, I always see the linker as a historical artifact came with C’s separate compilation model. With today’s more advanced compilers, we can definitely do better.

        Ideally, the compiler should be able to discover all source files from the entry point, parse and compile them in parallel, and spit out the final executable directly. Zig is probably the compiler closest to that ideal.

      3. 11

        This is really impressive. I wonder if you could build an interactive interpreter using this as it has such good compile speeds.

        1. 8

          I’m pretty sure I saw this being discussed during a live stream, and the answer was something like “probably, and that would be a cool project for someone to work on”. @kristoff or @andrewrk might be able to give a better answer.

        2. 6

          The current aim is to fully replace the C++ implementation with the self-hosted backend for Zig 0.8.0, roughly 7 months from now.

          Little concerned about bootstrapping now…

          1. 9


            Have a look at the build script. This is the current bootstrapping process and it’s the process that we will have at 1.0. I do reserve the right to regress this feature temporarily in between now and then.

            1. 3

              So essentially keeping the non-self-hosted implementation in “long term support” for bootstrap purposes, like LDC does? Good.

            2. 1

              Is that because the timeline is aggressive?

            3. 4

              I really like how Zig (creators) understood early that C must be a first class citizen and even more, and now you can actually compile C with Zig. Best decision ever I think. Otherwise IMO there is no way a compiled language can survive in a long run.

              Also Nim understood this from the beginning, Nim is translated (compiled?) to C.

              D understood it later, but still added betterC.

              Nice trend I think.

              1. 4

                Until now I never looked much into Zig, but I’ve read this article and the few linked and Zig really looks awesome. I’ve played a bit with C and assembly (back when I wasn’t a professional dev) and I really liked its simplicity and directness. Now after 22-ish years after these first small steps and having had quite a bit more exposure to other languages, I really like the (aparent) directness and simplicity of Zig.

                And with this feature set?

                1. 4

                  I wonder if they will end up implementing a C preprocessor in zig to allow import-c to work again. I have written parts of one before and its not too big in scope compared to zig already.

                  Consider https://github.com/michaelforney/cproc as a clean C compiler for reference.

                  1. 6

                    translate-c is already self-hosted and while it uses libclang for semantic analysis of C code, it does its own macro parsing to try to provide best effort macro translation

                    1. 2

                      I’d love to see QBE get a Wasm backend, possibly in Zig or Rust. I think it is important for Wasm to remain first class. I do like that Zig appears to removing a large C++ dependency, which means Zig will be less reliant on that whole stack, ecosystem and complexity. Zig gains a lot of agency over its future with this move.

                      No LLVM hate here, just like to see this decision being made now before Zig is over coupled to LLVM.

                    2. 2

                      I have a real dumb question. This is entirely ignorance, not a complaint: why are linkers slow when not using LTO? I don’t have any understanding of where all the milliseconds go. Hypothetically, could a linker that was designed to only work with PIC (to avoid relocations) be practically as fast as cat + a few dozen hash table lookups per function?

                      (Obviously it totally makes sense that LTO linking should be slow: the linker is doing a lot of work to optimise across what used to be module boundaries.)

                      1. 2

                        Impressive. Smart move.

                        1. 2

                          Congrats to Zig on this new milestone! This is a huge step.

                          1. 2

                            What does this mean, if anything, for zig cc? Will that still use clang and LLVM?

                            1. 1

                              replace the current C++ compiler implementation with a new pure Zig version

                              for a moment, I read this as “rewriting a C++ compiler in Zig” :D