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
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.
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?
> 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.
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/
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:
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.
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.
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.
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.
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)
Zig embeds clang to compile C code. This doesn't add a new dependency since Zig already depends on LLVM. If there is a future where the self-hosted Zig backend is good enough to not depend on LLVM anymore, there might be a reason to use a C compiler written in Zig (possibly https://github.com/Vexu/arocc)
Also worth noting that Zig embeds C stdlib source code (musl if I'm not mistaken). That means it is easier to cross compile C projects using zig since you don't need to install a cross toolchain. This is why some golang/rust projects use Zig when they need to cross compile.
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).
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.)
I'd like to add the link to the use examples demonstrating features of zig for c and c++ compilation available with the default zig installation which aren't directly available after installing clang:
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.
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?
I use VS Code on Linux to debug Zig. Haven't tried the others you mentioned, but it just emits standard DWARF symbols, so I'm guessing if you can debug C/C++ you could probably also do Zig with minimal changes? I just use the lldb VS code plugin[0], which works out of the box for me with no issues.
I've been able to debug Zig in Windows by simply opening the .exe file with Visual Studio. I didn't explore much what can be done in it but it is possible.
At least DWARF is supported (e.g. any gdb or lldb frontend works, e.g. what various VSCode extensions like CodeLLDB offer). Not sure about PDB support on Windows actually.
This also means you can transparently debug-step from Zig into C code and back, which is kinda expected but it never gets old for me :)
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.
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.
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.
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.
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.
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?
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.
I fell in love with the ninja build system recently. It's machine language for build systems, and I can write my own scripts to generate the ninja build file, rather than introducing any new language from someone else just for build descriptions.
Meson has the ability to generate code and process data files. Why do you need to communicate with REST? Meson support that however by allowing you to break out using the `run_command()` function.
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.
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.
Readit News
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/
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.
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!
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
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.
Deleted Comment
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.
Is it mainly due to the zig's caching of the build artifacts?
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)
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).
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.)
And not just C, but also C++ and Objective-C - including all the hairy stuff to create macOS executables without the Apple toolchain.
I'd like to add the link to the use examples demonstrating features of zig for c and c++ compilation available with the default zig installation which aren't directly available after installing clang:
https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
Previous discussions:
https://news.ycombinator.com/item?id=22679138
https://news.ycombinator.com/item?id=27872596
https://github.com/Not-Nik/raylib-zig
Since it’s zig code, I think you would have that flexibility.
https://github.com/vadimcn/codelldb
This also means you can transparently debug-step from Zig into C code and back, which is kinda expected but it never gets old for me :)
But even without LLVM backend I would expect that Zig will be able to produce DWARF debug information.
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/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
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.
Is ninja not expressive enough for your needs?
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.
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_formul...