10 ms·

Zig build system

185 points by SerCe 4y ago

kristoff_it 4y ago
The Zig build system is now able to run tasks in parallel. To avoid overloading the system (ie to prevent OOM) it asks you to define MaxRSS for each task, resulting in pretty sweet usage consumption: https://ibb.co/FW9kpxT https://ibb.co/FW9kpxT On a M1 Ultra studio (the same from my screenshot above) it takes me 6 mins to run the entire compiler test suite for arm64-linux (I do development in a Linux VM), which is pretty sweet. Note that this is one stepping stone for getting good performance from Zig, but it's not yet incremental compilation with in-place binary patching [1]. That's still a work in progress. [1] https://kristoff.it/blog/zig-new-relationship-llvm/ https://kristoff.it/blog/zig-new-relationship-llvm/
- ksec 4y ago
  Just want to say your first link trigger fraud protection alert.
- bonzini 4y ago
  Is it possible to use zig without the zig build system, in order to slowly integrate a new language in an existing program? For example, can I use the C backend to compile zig to C, and then use the system compiler as I would normally do with a meson cross file or CMake toolchain file?
  - acqq 4y ago
    If I understand your question it is: Is it possible to write zig modules which would be liked to the bigger project otherwise written in C, C++ & c? And moreover, to produce C "blobs" from zig sources which would be then part of the bigger project written in other languages? I'd also like to know the answer to both!
  - e4m2 4y ago
    > For example, can I use the C backend to compile zig to C, and then use the system compiler as I would normally do with a meson cross file or CMake toolchain file? It's possible, but: 1. The C backend isn't 100% there yet. You won't be able to use all features and might run into bugs. 2. The generated code won't be very readable, it's arguably not too different from just using Zig-compiled object files directly in terms of "opaqueness" and legibility. If neither of these are a big problem for you (both points are likely to improve with time), then yes, you could do that.
    - bonzini 4y ago
      Readability is not an issue, as long as there are #line directives and symbol names are preserved so it is possible to use gdb. The idea would be that if C files are reproducible across multiple environments (esp. 32 vs 64 bit) the end user would not need a zig toolchain.
    - AndyKelley 4y ago
      To supply a data point: As of Zig 0.11.0-dev.2615+0733c8c5c, on an x86_64-linux host, the C backend is passing 1568 behavior tests compared to 1587 behavior tests passed by the LLVM backend on the same host. So, yes, it is not 100% there yet - it is 99% there :-)
      - e4m2 4y ago
        Ah, good to know! My main sources were the release notes and occasionally your tweets (the account seems to have gotten suspended?), so my information was understandably a bit out of date. Glad to see progress being made though.
      - therein 4y ago
        I feel like Zig can dominate the shellcode space, especially with pluggable allocators and minimalism. Is there any work towards outputting a naked payload for the lack of a better word? Given just the ISA, calling convention etc., producing something that starts from main() and does nothing but what is contained within main?
  - kristoff_it 4y ago
    Totally, just use `zig cc` as an in-place replacement for clang and move forward from there as you feel comfrotable. I wrote a blog post about this approach: https://kristoff.it/blog/maintain-it-with-zig/ https://kristoff.it/blog/maintain-it-with-zig/
    - bonzini 4y ago
      I am asking for the opposite, i.e. keep everything as is and only add 2-300 lines of zig. In particular, I explicitly don't want to rewrite 15000 lines of build system code, so anything that uses build.zig is a nonstarter.
      - gpanders 4y ago
        You can invoke Zig without build.zig: zig build-obj file.zig And then include the object file along with your other sources. How you do this will of course depend on your build system.
eru 4y ago
Interesting. I wonder if it allows adding dependencies at runtime? (As explained in eg http://simonmar.github.io/bib/papers/shake.pdf http://simonmar.github.io/bib/papers/shake.pdf )
- jmull 4y ago
  You mean when the build runs? Since it’s zig code, I think you would have that flexibility.
  - eru 4y ago
    Yes, dependencies you only discover as you run the build.
Alifatisk 4y ago
Why is Zigs syntax so ... foreign?
- mauricioc 4y ago
  To whom?
  - Alifatisk 4y ago
    To me, for example. > .{}
    - deleted 4y ago
      [deleted]
    - brabel 4y ago
      Is C foreign to you? Zig syntax is nearly identical to how C initializes structs.
    - mauricioc 4y ago
      For the example you cited (anonymous struct literals), there are two parts to it: 1) It omits the constructor name. My uneducated guess is that "modern" languages try to avoid the Java-style pattern of repeating a type/constructor many times in a single line (e.g., "Point pt = new Point(0, 0)") when it can infer things to help the developer. 2) It starts with a dot, while C++'s compound literals (for example) don't. The pros and cons of this are discussed in https://github.com/ziglang/zig/issues/5039 https://github.com/ziglang/zig/issues/5039.
    - kristoff_it 4y ago
      That's the same as using `{}` in C to initialize a struct. The dot only makes more clear that it's a struct literal and not a scope.
    - jussij 4y ago
      The language cetainly seems to like using that 'dot' operator: const exe = b.addExecutable(.{ .name = "demo", .root_source_file = .{ .path = "src/main.zig" }, .target = target, .optimize = optimize, });
quirino 4y ago
I've been confused by the statement that "Zig can compile C Code" for quite some time and reading a couple of blog posts hasn't made it much clearer. Does the Zig Project include a full blown C Compiler? Is it the Zig Compiler with some sort of adaptation to compile C code? Or does it use something like Clang behind the curtains? (In this case it would be responsible for some other parts of the compilation process)
- lionkor 4y ago
  I believe the answer is two-fold: 1. It uses LLVM as the default backend, in which case that handles C as well 2. Optionally, and in the future by default, the Zig backend (a different one from the LLVM one) includes a C compiler (?) Something like that. Its very powerful and it has the best C integration of any language in my experience (better than C++ since it effectively namespaces C headers).
  - quirino 4y ago
    Thanks for the answer but some things are still not entirely clear. Who would be doing the parsing of C code for instance? Clang is also based LLVM but it is responsible for a load of C-specific stuff like parsing the language and feeding it into LLVM for instance. I've got little experience with this stuff so I'm not sure if my questions even make that much sense. (Edit: I believe ptato has answered my question above.)
    - kristoff_it 4y ago
      You can invoke `zig cc` with the same flags that you would pass to `clang`. Zig cc takes your arguments, inspects them and applies some transformations and then Zig invokes its internal copy of clang with the resulting flags. One example of transformation is enabling ubsan when building in debug mode, another is `-target` which makes Zig add some sysroot flags to enable cross-compilation. In this case all the file operations are handled by clang, Zig basically just sets up all the advanced flags for you when it makes sense to do so. One last example of CLI rewriting is related to the caching system: Zig cc knows how to cache a build by passing to clang the same kind of flags that cmake (or other build systems) would. There's another C-related feature of Zig that works differently: `@cImport()`, which is a builtin that allows you to import C header files directly into a Zig script, in order to use from Zig all the types exposed by the header file. This one translates the C syntax in equivalent Zig syntax. I believe it uses clang's code to parse the C code into an AST, but then it's all Zig logic from there. Lastly, we have a C frontend project going (arocc, linked by ptato) on that we plan to eventually upstream into Zig. This would be a replacement for clang and would work by parsing the C code and translating it into Zig IR, similarly to how the D programming language does it. The only limitation of this approach is that it would only support C, not C++, so we would either have to still keep clang around for C++, or ditch clang but then lose C++ compilation support. That said, even in the case where we keep clang around for C++ support, it would be worth having a custom C frontend for the Zig compiler in order to have more fine-grained control over the compilation process than what we can get from clang, plus the fact that it would make debug builds faster, since we could avoid invoking LLVM completely in that case (ie debug builds) even if you depend on C code.
adelm 4y ago
I take it so that zig build system is Turing complete, isn't it? There is a reason why, for example, meson build system DSL is made to be non-Turing complete. It makes reasoning much simpler.
- pron 4y ago
  When it comes to reasoning ability, Turing-completeness is a red herring. Turing-completeness falls beyond the reasoning ability of something that has unbounded computational power and unbounded patience, but because people only have access to bounded computational power and have bounded patience, their limit of feasible reasoning are well below Turing-completeness. A language with nothing but boolean variables and functions with no recursion, or a language with nothing but boolean variables and loops of up to a depth of 2 can already encode TQBF [1], which makes reasoning about it intractable (it's PSPACE-complete). Because most build systems fall within that category they might as well be Turing complete. [1]: https://en.wikipedia.org/wiki/True_quantified_Boolean_formula https://en.wikipedia.org/wiki/True_quantified_Boolean_formul...
- gavinhoward 4y ago
  Yes, it makes reasoning simpler. But then some things become impossible to do. I'm creating a different build system (not Zig's), and I'm taking a different approach. Instead of a non-Turing-complete language, I've made one that is as powerful as possible. However, it will allow users to restrict the language so that they will only use subsets, and those subsets will not necessarily be Turing-complete. In this way, it has the power to do anything, but the ability to restrict that power for ease-of-use.
- flohofwoe 4y ago
  IME you really need a programming language to describe a build, even when it is desired that the result looks 'mostly declarative' in the end. E.g. not sure how Meson handles this, but when I have a project with dozens of similar build targets and platform specific compile options, I really want to do the build description in a loop instead of a data tree. (for example: https://github.com/floooh/sokol-zig/blob/3f978e58712f9eb029ba47d4362f3ca4caff5036/build.zig#L152-L175 https://github.com/floooh/sokol-zig/blob/3f978e58712f9eb029b...) PS: apparently Meson build scripts can also have variables, conditions and loops, which I guess makes the difference to an actually Turing complete build system rather esoterical? https://mesonbuild.com/Syntax.html#logical-operations https://mesonbuild.com/Syntax.html#logical-operations A proper build system is so much more than just describing build targets and their dependencies, you also want to generate source code, copy and process data files, communicate with REST services etc... The more this happens in a 'real' programming language the better.
Hnus 4y ago
Can you debug zig in any MS/jetbrains IDEs? I type in nvim but debug in whatever has the best experience. I think I asked this question like 2 years ago and was told you can write tests, use lsp server or look at assembly.. has situation improved?
- duckqlz 4y ago
  The best debugging experience imo is using gdb and rr within nvim. Works for zig, c, rust, etc. with minimal configuration in nvim. The less I leave vim the more productive I can be. Same thing probably goes for emacs although I will never admit it.
  - immrammc 4y ago
    I’d love if you could elaborate on your setup. Are you using something like nvim-dap from within neovim or something else? I’m still trying to improve my debug experience in neovim.
    - fileeditview 4y ago
      Would also love to hear more. I have nvim-dap set up for Go and for C and it is an OK experience but I would not call it great. This is something on my Neovim todo list.. improving my debugging experience.
- sciolistse 4y ago
  Not so sure about any real IDEs, lldb has worked fine for the (fairly small) zig programs I've worked on and the "CodeLLDB" vscode extension worked. Of course with the move from LLVM i assume lldb will stop working, and vscode may not be a good enough debugging experience.
  - flohofwoe 4y ago
    AFAIK the LLVM backend won't go away in the standard Zig distribution even with the new non-LLVM backend. But even without LLVM backend I would expect that Zig will be able to produce DWARF debug information.
rtkwe 4y ago
Someone needs to make a competing build system called Zag, just so I can eventually make the joke "we Zigged where we should have Zagged" after Zig has some major issue in our build env.
- klyrs 4y ago
  I want Zag to be what Python is to C.
  - rtkwe 4y ago
    That's another fun option and opens up a whole new branch of fun like ZigZag a compatibility layer for running Zig builds in Zag.
  - slowking2 4y ago
    Had the same thought. The naming synergy is perfect.
- winrid 4y ago
  Ringworld reference?
- ksec 4y ago
  Once Zig is done, may be Zag could be a superset of Zig where it focuses on application and slightly higher level development. Think C++, Swift and Java.
jedisct1 4y ago
libsodium is written in C and Assembly, but uses Zig as an alternative to autoconf/make/etc. Builds are much faster than with make, and it makes it very easy to cross-compile to other platform, includes Windows, Linux with specific glibc versions, and WebAssembly. In fact, it was the easiest to build Linux binaries for .NET, that have to support glibc back to version 2.17, but on a recent OS, with a recent compiler toolchain.
- acqq 4y ago
  Can you write about the reasons for much faster builds, as far as you know? Is it mainly due to the zig's caching of the build artifacts?
  - aidenn0 4y ago
    I'm not who you are replying to, but it's almost certainly due to autoconf &c. For many libraries on a machine with lots of cores, autoconf can take longer than the build, since autoconf isn't parallelized.
    - ploxiln 4y ago
      Also, IIRC, many smaller projects using autoconf have copied in a bunch of boilerplate feature tests that they don't need, like "is strncpy available" "is snprintf available" "does realloc NULL work". As you mention, each one of these tests generates and compiles a minimal C file, and not in parallel. (And each test generates/defines a HAVE_SNPRINTF etc macro that your code can use to adapt based on available features. But if the project isn't as big as curl or git, it probably doesn't really adapt to all possible old and obscure systems anyway, so there's no point to 100s of such tests.)
      - acqq 4y ago
        Thanks, both are good general tips, but in this specific case https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium I would guess that the author of the library has full control both over optimal parallelization of a build and minimal autoconf, but he can still observe a huge speedup, so I'd still like to read his answer.
synergy20 4y ago
zig looks like a 'better C', is there a list of something it does better than C(e.g. integer promotion,UB,etc), so that I should embrace it quickly and start to use it in my embedded projects? would like to see a comparison table between zig vs c (or even c++)
- tarruda 4y ago
  I did a bit of Zig exploration a few months ago, here's a few things that caught my attention: - You don't have implicit allocations when using Zig stdlib. For example, when you instantiate an ArrayList or HashMap, you need to pass in an allocator, so you have full control over how memory is managed. So, even though you have higher level data structures, you still have a lot of low level control. - Very good error handling. IMO better than Rust and Golang, while still being very explicit about what is happening - "Uncolored" async functions, meaning there's no special syntax for declaring functions that can be paused/resumed. If I understood correctly (didn't try it a lot), you can turn any program into "async" by changing how I/O is handled globally. More details here: https://kristoff.it/blog/zig-colorblind-async-await/ https://kristoff.it/blog/zig-colorblind-async-await/
- kristoff_it 4y ago
  Here's a nice overview of Zig that should make even more sense if you know C: https://ziglang.org/learn/overview/ https://ziglang.org/learn/overview/
- flohofwoe 4y ago
  As far as language features go: extensive comptime support, error handling and optionals integrated into the language, a new (to me at least) twist on generics, type reflection, and a couple of smaller 'convenience features' like type inference, if and switch being expressions, etc... Reading this from top to bottom gives a pretty good overview: https://ziglang.org/documentation/master/ https://ziglang.org/documentation/master/
- fileeditview 4y ago
  I would recommend this talk by the creator of Zig: https://www.youtube.com/watch?v=Gv2I7qTux7g&t=3021s https://www.youtube.com/watch?v=Gv2I7qTux7g&t=3021s He gives some examples of C vs Zig and what they tried to improve.
diimdeep 4y ago
Looks like people behind Zig decided to drop support for macOS Catalina, OS released just 3 years ago. So it is not possible to compile Zig for it. It is ridiculous. https://github.com/ziglang/zig/issues/13313#issuecomment-1296440303 https://github.com/ziglang/zig/issues/13313#issuecomment-129...
- bbkane 4y ago
  Maybe they'd accept a PR if you volunteer to maintain that work?
- kristoff_it 4y ago
  As "ridiculous" as it might be, we're a small non-profit and have to prioritize where to allocate our resources as we develop Zig. When it comes to macOS, we follow the same policy as Apple: support the latest 3 versions of it. Maybe once Zig is fully developed we'll focus our effort on more retrocompatibility. If you want to help us get there faster, consider donating to the Zig software foundation, as we're looking to hire more developers to work full time on Zig (we're 4 full-time people right now). https://ziglang.org/zsf/ https://ziglang.org/zsf/
  - diimdeep 4y ago
    No, I will not donate, because I think that my money will be spend on unnecessary effort of removing already supported targets, instead of meaningful tasks, like writing simple check in CMake to indicate that given OS is not supported instead of failing with vague error message on link time step.
    - YorickPeterse 4y ago
      Honestly that just sounds like "I want things for free, but I'm not willing to give back anything in return".
  - diimdeep 4y ago
    Even though as you say atm. Apple does not support <=10.15. Latest Xcode 14.3 still supports building applications that target macOS 10.13.[1] So that is not an excuse to drop support for 10.15. [1] https://developer.apple.com/support/xcode/ https://developer.apple.com/support/xcode/
eggy 4y ago
Glad to see a Zig Build for Raylib. I am using Zig to compile most of my C stuff now as I learn Zig. This makes Zig much more attractive to anyone considering learning it. It's easier than Make and CMake for me.
- hiccuphippo 4y ago
  There's also a project that generates automatic bindings for raylib: https://github.com/Not-Nik/raylib-zig https://github.com/Not-Nik/raylib-zig
malkia 4y ago
But why?
AndyKelley 4y ago
If you want to see a fun example of this build system in action, have a look at my ffmpeg fork which has the build system ported to zig build: https://github.com/andrewrk/ffmpeg https://github.com/andrewrk/ffmpeg Particularly interesting is the use of nasm as a package dependency, which is executed to compile many assembly files into object files, which are then linked into the ffmpeg static library. I'm using this package in a work-in-progress reboot of Groove Basin (a music player server) in Zig: https://github.com/andrewrk/groovebasin/tree/zig-pkg https://github.com/andrewrk/groovebasin/tree/zig-pkg Point being that if you want to collaborate on the music player project, you don't need to screw around with a million system dependencies, it's just `zig build` and you're off to the races - no matter whether you are using Windows, macOS, or Linux. The zig build system is under heavy construction during this release cycle of Zig. I recommend to check it out at the end of May when Zig 0.11.0 is released, and a few more issues will be smoothed over. Of course, if you want to get your hands dirty and help work on a bleeding-edge build system & package manager, come on over and give master branch a try.
- whitehexagon 4y ago
  First time I have seen the dotty zon file, it looks like zig anonymous struct syntax? If so, does that mean the structs/information in the zon file can be merged/included directly into the build.zig file where the dependencies are mentioned again? ie avoiding the zon file altogether? Maybe it is documented? but you are all working so fast I cant keep up :) I saw a http client/server push (btw nice!) that seemed to also include some new syntax that I wasnt familiar with; for(n..n2) etc. Anyway exciting times and great to see solid progress, well done.
  - kristoff_it 4y ago
    I made a blog post about the new for loop syntax (spoilers: ranges are only one of the new features): https://kristoff.it/blog/zig-multi-sequence-for-loops/ https://kristoff.it/blog/zig-multi-sequence-for-loops/
  - deleted 4y ago
    [deleted]
64bittechie 4y ago
[dead]
scrubs 4y ago
I'm holding my breath. The first day out I ran into a link problem. Zig linked statically not dynamically as instructed and while the task was produced, it didn't work anyway. That's not gonna be fixed I believe until 0.11.0. now to give credit where due, the head guy (Andrew if I recall) had already found this issue or a good part of it.

185 points by SerCe 4y ago

The Zig build system is now able to run tasks in parallel. To avoid overloading the system (ie to prevent OOM) it asks you to define MaxRSS for each task, resulting in pretty sweet usage consumption: https://ibb.co/FW9kpxT https://ibb.co/FW9kpxT On a M1 Ultra studio (the same from my screenshot above) it takes me 6 mins to run the entire compiler test suite for arm64-linux (I do development in a Linux VM), which is pretty sweet. Note that this is one stepping stone for getting good performance from Zig, but it's not yet incremental compilation with in-place binary patching [1]. That's still a work in progress. [1] https://kristoff.it/blog/zig-new-relationship-llvm/ https://kristoff.it/blog/zig-new-relationship-llvm/

ksec 4y ago
Just want to say your first link trigger fraud protection alert.
bonzini 4y ago
Is it possible to use zig without the zig build system, in order to slowly integrate a new language in an existing program? For example, can I use the C backend to compile zig to C, and then use the system compiler as I would normally do with a meson cross file or CMake toolchain file?
- acqq 4y ago
  If I understand your question it is: Is it possible to write zig modules which would be liked to the bigger project otherwise written in C, C++ & c? And moreover, to produce C "blobs" from zig sources which would be then part of the bigger project written in other languages? I'd also like to know the answer to both!
- e4m2 4y ago
  > For example, can I use the C backend to compile zig to C, and then use the system compiler as I would normally do with a meson cross file or CMake toolchain file? It's possible, but: 1. The C backend isn't 100% there yet. You won't be able to use all features and might run into bugs. 2. The generated code won't be very readable, it's arguably not too different from just using Zig-compiled object files directly in terms of "opaqueness" and legibility. If neither of these are a big problem for you (both points are likely to improve with time), then yes, you could do that.
  - bonzini 4y ago
    Readability is not an issue, as long as there are #line directives and symbol names are preserved so it is possible to use gdb. The idea would be that if C files are reproducible across multiple environments (esp. 32 vs 64 bit) the end user would not need a zig toolchain.
  - AndyKelley 4y ago
    To supply a data point: As of Zig 0.11.0-dev.2615+0733c8c5c, on an x86_64-linux host, the C backend is passing 1568 behavior tests compared to 1587 behavior tests passed by the LLVM backend on the same host. So, yes, it is not 100% there yet - it is 99% there :-)
    - e4m2 4y ago
      Ah, good to know! My main sources were the release notes and occasionally your tweets (the account seems to have gotten suspended?), so my information was understandably a bit out of date. Glad to see progress being made though.
    - therein 4y ago
      I feel like Zig can dominate the shellcode space, especially with pluggable allocators and minimalism. Is there any work towards outputting a naked payload for the lack of a better word? Given just the ISA, calling convention etc., producing something that starts from main() and does nothing but what is contained within main?
- kristoff_it 4y ago
  Totally, just use `zig cc` as an in-place replacement for clang and move forward from there as you feel comfrotable. I wrote a blog post about this approach: https://kristoff.it/blog/maintain-it-with-zig/ https://kristoff.it/blog/maintain-it-with-zig/
  - bonzini 4y ago
    I am asking for the opposite, i.e. keep everything as is and only add 2-300 lines of zig. In particular, I explicitly don't want to rewrite 15000 lines of build system code, so anything that uses build.zig is a nonstarter.
    - gpanders 4y ago
      You can invoke Zig without build.zig: zig build-obj file.zig And then include the object file along with your other sources. How you do this will of course depend on your build system.

eru 4y ago

Interesting. I wonder if it allows adding dependencies at runtime? (As explained in eg http://simonmar.github.io/bib/papers/shake.pdf http://simonmar.github.io/bib/papers/shake.pdf )

jmull 4y ago
You mean when the build runs? Since it’s zig code, I think you would have that flexibility.
- eru 4y ago
  Yes, dependencies you only discover as you run the build.

Alifatisk 4y ago

Why is Zigs syntax so ... foreign?

mauricioc 4y ago
To whom?
- Alifatisk 4y ago
  To me, for example. > .{}
  - deleted 4y ago
    [deleted]
  - brabel 4y ago
    Is C foreign to you? Zig syntax is nearly identical to how C initializes structs.
  - mauricioc 4y ago
    For the example you cited (anonymous struct literals), there are two parts to it: 1) It omits the constructor name. My uneducated guess is that "modern" languages try to avoid the Java-style pattern of repeating a type/constructor many times in a single line (e.g., "Point pt = new Point(0, 0)") when it can infer things to help the developer. 2) It starts with a dot, while C++'s compound literals (for example) don't. The pros and cons of this are discussed in https://github.com/ziglang/zig/issues/5039 https://github.com/ziglang/zig/issues/5039.
  - kristoff_it 4y ago
    That's the same as using `{}` in C to initialize a struct. The dot only makes more clear that it's a struct literal and not a scope.
  - jussij 4y ago
    The language cetainly seems to like using that 'dot' operator: const exe = b.addExecutable(.{ .name = "demo", .root_source_file = .{ .path = "src/main.zig" }, .target = target, .optimize = optimize, });

quirino 4y ago

I've been confused by the statement that "Zig can compile C Code" for quite some time and reading a couple of blog posts hasn't made it much clearer. Does the Zig Project include a full blown C Compiler? Is it the Zig Compiler with some sort of adaptation to compile C code? Or does it use something like Clang behind the curtains? (In this case it would be responsible for some other parts of the compilation process)

lionkor 4y ago
I believe the answer is two-fold: 1. It uses LLVM as the default backend, in which case that handles C as well 2. Optionally, and in the future by default, the Zig backend (a different one from the LLVM one) includes a C compiler (?) Something like that. Its very powerful and it has the best C integration of any language in my experience (better than C++ since it effectively namespaces C headers).
- quirino 4y ago
  Thanks for the answer but some things are still not entirely clear. Who would be doing the parsing of C code for instance? Clang is also based LLVM but it is responsible for a load of C-specific stuff like parsing the language and feeding it into LLVM for instance. I've got little experience with this stuff so I'm not sure if my questions even make that much sense. (Edit: I believe ptato has answered my question above.)
  - kristoff_it 4y ago
    You can invoke `zig cc` with the same flags that you would pass to `clang`. Zig cc takes your arguments, inspects them and applies some transformations and then Zig invokes its internal copy of clang with the resulting flags. One example of transformation is enabling ubsan when building in debug mode, another is `-target` which makes Zig add some sysroot flags to enable cross-compilation. In this case all the file operations are handled by clang, Zig basically just sets up all the advanced flags for you when it makes sense to do so. One last example of CLI rewriting is related to the caching system: Zig cc knows how to cache a build by passing to clang the same kind of flags that cmake (or other build systems) would. There's another C-related feature of Zig that works differently: `@cImport()`, which is a builtin that allows you to import C header files directly into a Zig script, in order to use from Zig all the types exposed by the header file. This one translates the C syntax in equivalent Zig syntax. I believe it uses clang's code to parse the C code into an AST, but then it's all Zig logic from there. Lastly, we have a C frontend project going (arocc, linked by ptato) on that we plan to eventually upstream into Zig. This would be a replacement for clang and would work by parsing the C code and translating it into Zig IR, similarly to how the D programming language does it. The only limitation of this approach is that it would only support C, not C++, so we would either have to still keep clang around for C++, or ditch clang but then lose C++ compilation support. That said, even in the case where we keep clang around for C++ support, it would be worth having a custom C frontend for the Zig compiler in order to have more fine-grained control over the compilation process than what we can get from clang, plus the fact that it would make debug builds faster, since we could avoid invoking LLVM completely in that case (ie debug builds) even if you depend on C code.

adelm 4y ago

I take it so that zig build system is Turing complete, isn't it? There is a reason why, for example, meson build system DSL is made to be non-Turing complete. It makes reasoning much simpler.

pron 4y ago
When it comes to reasoning ability, Turing-completeness is a red herring. Turing-completeness falls beyond the reasoning ability of something that has unbounded computational power and unbounded patience, but because people only have access to bounded computational power and have bounded patience, their limit of feasible reasoning are well below Turing-completeness. A language with nothing but boolean variables and functions with no recursion, or a language with nothing but boolean variables and loops of up to a depth of 2 can already encode TQBF [1], which makes reasoning about it intractable (it's PSPACE-complete). Because most build systems fall within that category they might as well be Turing complete. [1]: https://en.wikipedia.org/wiki/True_quantified_Boolean_formula https://en.wikipedia.org/wiki/True_quantified_Boolean_formul...
gavinhoward 4y ago
Yes, it makes reasoning simpler. But then some things become impossible to do. I'm creating a different build system (not Zig's), and I'm taking a different approach. Instead of a non-Turing-complete language, I've made one that is as powerful as possible. However, it will allow users to restrict the language so that they will only use subsets, and those subsets will not necessarily be Turing-complete. In this way, it has the power to do anything, but the ability to restrict that power for ease-of-use.
flohofwoe 4y ago
IME you really need a programming language to describe a build, even when it is desired that the result looks 'mostly declarative' in the end. E.g. not sure how Meson handles this, but when I have a project with dozens of similar build targets and platform specific compile options, I really want to do the build description in a loop instead of a data tree. (for example: https://github.com/floooh/sokol-zig/blob/3f978e58712f9eb029ba47d4362f3ca4caff5036/build.zig#L152-L175 https://github.com/floooh/sokol-zig/blob/3f978e58712f9eb029b...) PS: apparently Meson build scripts can also have variables, conditions and loops, which I guess makes the difference to an actually Turing complete build system rather esoterical? https://mesonbuild.com/Syntax.html#logical-operations https://mesonbuild.com/Syntax.html#logical-operations A proper build system is so much more than just describing build targets and their dependencies, you also want to generate source code, copy and process data files, communicate with REST services etc... The more this happens in a 'real' programming language the better.

Hnus 4y ago

Can you debug zig in any MS/jetbrains IDEs? I type in nvim but debug in whatever has the best experience. I think I asked this question like 2 years ago and was told you can write tests, use lsp server or look at assembly.. has situation improved?

duckqlz 4y ago
The best debugging experience imo is using gdb and rr within nvim. Works for zig, c, rust, etc. with minimal configuration in nvim. The less I leave vim the more productive I can be. Same thing probably goes for emacs although I will never admit it.
- immrammc 4y ago
  I’d love if you could elaborate on your setup. Are you using something like nvim-dap from within neovim or something else? I’m still trying to improve my debug experience in neovim.
  - fileeditview 4y ago
    Would also love to hear more. I have nvim-dap set up for Go and for C and it is an OK experience but I would not call it great. This is something on my Neovim todo list.. improving my debugging experience.
sciolistse 4y ago
Not so sure about any real IDEs, lldb has worked fine for the (fairly small) zig programs I've worked on and the "CodeLLDB" vscode extension worked. Of course with the move from LLVM i assume lldb will stop working, and vscode may not be a good enough debugging experience.
- flohofwoe 4y ago
  AFAIK the LLVM backend won't go away in the standard Zig distribution even with the new non-LLVM backend. But even without LLVM backend I would expect that Zig will be able to produce DWARF debug information.

rtkwe 4y ago

Someone needs to make a competing build system called Zag, just so I can eventually make the joke "we Zigged where we should have Zagged" after Zig has some major issue in our build env.

klyrs 4y ago
I want Zag to be what Python is to C.
- rtkwe 4y ago
  That's another fun option and opens up a whole new branch of fun like ZigZag a compatibility layer for running Zig builds in Zag.
- slowking2 4y ago
  Had the same thought. The naming synergy is perfect.
winrid 4y ago
Ringworld reference?
ksec 4y ago
Once Zig is done, may be Zag could be a superset of Zig where it focuses on application and slightly higher level development. Think C++, Swift and Java.

jedisct1 4y ago

libsodium is written in C and Assembly, but uses Zig as an alternative to autoconf/make/etc. Builds are much faster than with make, and it makes it very easy to cross-compile to other platform, includes Windows, Linux with specific glibc versions, and WebAssembly. In fact, it was the easiest to build Linux binaries for .NET, that have to support glibc back to version 2.17, but on a recent OS, with a recent compiler toolchain.

acqq 4y ago
Can you write about the reasons for much faster builds, as far as you know? Is it mainly due to the zig's caching of the build artifacts?
- aidenn0 4y ago
  I'm not who you are replying to, but it's almost certainly due to autoconf &c. For many libraries on a machine with lots of cores, autoconf can take longer than the build, since autoconf isn't parallelized.
  - ploxiln 4y ago
    Also, IIRC, many smaller projects using autoconf have copied in a bunch of boilerplate feature tests that they don't need, like "is strncpy available" "is snprintf available" "does realloc NULL work". As you mention, each one of these tests generates and compiles a minimal C file, and not in parallel. (And each test generates/defines a HAVE_SNPRINTF etc macro that your code can use to adapt based on available features. But if the project isn't as big as curl or git, it probably doesn't really adapt to all possible old and obscure systems anyway, so there's no point to 100s of such tests.)
    - acqq 4y ago
      Thanks, both are good general tips, but in this specific case https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium I would guess that the author of the library has full control both over optimal parallelization of a build and minimal autoconf, but he can still observe a huge speedup, so I'd still like to read his answer.

synergy20 4y ago

zig looks like a 'better C', is there a list of something it does better than C(e.g. integer promotion,UB,etc), so that I should embrace it quickly and start to use it in my embedded projects? would like to see a comparison table between zig vs c (or even c++)

tarruda 4y ago
I did a bit of Zig exploration a few months ago, here's a few things that caught my attention: - You don't have implicit allocations when using Zig stdlib. For example, when you instantiate an ArrayList or HashMap, you need to pass in an allocator, so you have full control over how memory is managed. So, even though you have higher level data structures, you still have a lot of low level control. - Very good error handling. IMO better than Rust and Golang, while still being very explicit about what is happening - "Uncolored" async functions, meaning there's no special syntax for declaring functions that can be paused/resumed. If I understood correctly (didn't try it a lot), you can turn any program into "async" by changing how I/O is handled globally. More details here: https://kristoff.it/blog/zig-colorblind-async-await/ https://kristoff.it/blog/zig-colorblind-async-await/
kristoff_it 4y ago
Here's a nice overview of Zig that should make even more sense if you know C: https://ziglang.org/learn/overview/ https://ziglang.org/learn/overview/
flohofwoe 4y ago
As far as language features go: extensive comptime support, error handling and optionals integrated into the language, a new (to me at least) twist on generics, type reflection, and a couple of smaller 'convenience features' like type inference, if and switch being expressions, etc... Reading this from top to bottom gives a pretty good overview: https://ziglang.org/documentation/master/ https://ziglang.org/documentation/master/
fileeditview 4y ago
I would recommend this talk by the creator of Zig: https://www.youtube.com/watch?v=Gv2I7qTux7g&t=3021s https://www.youtube.com/watch?v=Gv2I7qTux7g&t=3021s He gives some examples of C vs Zig and what they tried to improve.

diimdeep 4y ago

Looks like people behind Zig decided to drop support for macOS Catalina, OS released just 3 years ago. So it is not possible to compile Zig for it. It is ridiculous. https://github.com/ziglang/zig/issues/13313#issuecomment-1296440303 https://github.com/ziglang/zig/issues/13313#issuecomment-129...

bbkane 4y ago
Maybe they'd accept a PR if you volunteer to maintain that work?
kristoff_it 4y ago
As "ridiculous" as it might be, we're a small non-profit and have to prioritize where to allocate our resources as we develop Zig. When it comes to macOS, we follow the same policy as Apple: support the latest 3 versions of it. Maybe once Zig is fully developed we'll focus our effort on more retrocompatibility. If you want to help us get there faster, consider donating to the Zig software foundation, as we're looking to hire more developers to work full time on Zig (we're 4 full-time people right now). https://ziglang.org/zsf/ https://ziglang.org/zsf/
- diimdeep 4y ago
  No, I will not donate, because I think that my money will be spend on unnecessary effort of removing already supported targets, instead of meaningful tasks, like writing simple check in CMake to indicate that given OS is not supported instead of failing with vague error message on link time step.
  - YorickPeterse 4y ago
    Honestly that just sounds like "I want things for free, but I'm not willing to give back anything in return".
- diimdeep 4y ago
  Even though as you say atm. Apple does not support <=10.15. Latest Xcode 14.3 still supports building applications that target macOS 10.13.[1] So that is not an excuse to drop support for 10.15. [1] https://developer.apple.com/support/xcode/ https://developer.apple.com/support/xcode/

eggy 4y ago

Glad to see a Zig Build for Raylib. I am using Zig to compile most of my C stuff now as I learn Zig. This makes Zig much more attractive to anyone considering learning it. It's easier than Make and CMake for me.

hiccuphippo 4y ago
There's also a project that generates automatic bindings for raylib: https://github.com/Not-Nik/raylib-zig https://github.com/Not-Nik/raylib-zig

malkia 4y ago

But why?

AndyKelley 4y ago

If you want to see a fun example of this build system in action, have a look at my ffmpeg fork which has the build system ported to zig build: https://github.com/andrewrk/ffmpeg https://github.com/andrewrk/ffmpeg Particularly interesting is the use of nasm as a package dependency, which is executed to compile many assembly files into object files, which are then linked into the ffmpeg static library. I'm using this package in a work-in-progress reboot of Groove Basin (a music player server) in Zig: https://github.com/andrewrk/groovebasin/tree/zig-pkg https://github.com/andrewrk/groovebasin/tree/zig-pkg Point being that if you want to collaborate on the music player project, you don't need to screw around with a million system dependencies, it's just `zig build` and you're off to the races - no matter whether you are using Windows, macOS, or Linux. The zig build system is under heavy construction during this release cycle of Zig. I recommend to check it out at the end of May when Zig 0.11.0 is released, and a few more issues will be smoothed over. Of course, if you want to get your hands dirty and help work on a bleeding-edge build system & package manager, come on over and give master branch a try.

whitehexagon 4y ago
First time I have seen the dotty zon file, it looks like zig anonymous struct syntax? If so, does that mean the structs/information in the zon file can be merged/included directly into the build.zig file where the dependencies are mentioned again? ie avoiding the zon file altogether? Maybe it is documented? but you are all working so fast I cant keep up :) I saw a http client/server push (btw nice!) that seemed to also include some new syntax that I wasnt familiar with; for(n..n2) etc. Anyway exciting times and great to see solid progress, well done.
- kristoff_it 4y ago
  I made a blog post about the new for loop syntax (spoilers: ranges are only one of the new features): https://kristoff.it/blog/zig-multi-sequence-for-loops/ https://kristoff.it/blog/zig-multi-sequence-for-loops/
- deleted 4y ago
  [deleted]

64bittechie 4y ago

[dead]

scrubs 4y ago

I'm holding my breath. The first day out I ran into a link problem. Zig linked statically not dynamically as instructed and while the task was produced, it didn't work anyway. That's not gonna be fixed I believe until 0.11.0. now to give credit where due, the head guy (Andrew if I recall) had already found this issue or a good part of it.