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?
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'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)
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).
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 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'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.
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.
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++)
Zig things that I miss when I have to go back to C:
- All integer operations trap on overflow in safe build modes; with explicit operators for saturating or wrapping arithmetic
- No implicit integer promotion unless the destination type can represent all values of the source type (so no implicit signed/unsigned conversions unless they're statically guaranteed to be safe - e.g. a u8 can coerce to an i32 but not to an i8)
- Arbitrary bit-size integers (C23 will have this)
- Enums that are actually useful and fun, vs the complete waste of time that C's enums are (Enum values are namespaced, you can't directly use their values as integers, you can control the underlying representation if you want, etc)
- Built-in support for tagged unions, also known as sum types (bare union + a tag indicating which field is active)
- Safe unions in safe build modes (compiler inserts a hidden tag to track which field is active)
- A standard library that's actually useful (it's small compared to some other languages, and not well-documented yet, but it's not littered with landmines the way C's is)
- A modern import system instead of preprocessor-style copy/pasting text
- Compile-time programming in Zig, instead of preprocessor macros
- Arrays are an actual type, instead of decaying to pointers
- Much better support for pointers (pointer + length AKA slices are the primary way to deal with multiple items whose length can vary at runtime; also single-item pointers and multi-item pointers are different types, so you can't accidentally index into a single-item pointer or attempt to dereference a multi-item pointer without providing an index)
- Errors must be handled, with convenient syntax for passing the error up the stack + inferred error sets so that you don't have to explicitly annotate the set of possible errors for most functions
- Nulls encoded in the type system so that they must be explicitly handled.
- test blocks for writing tests inline and running them with `zig test`
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/
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:
The word for German in many Slavic regions is something like Njemacki (and similar). Loosely translated it means "Those who cannot speak".
Of course, Germans can speak and languages of German descent are just as rich, precise and expressive as any other. But the term Njemacki probably stuck around out of an initial ignorance about a foreign culture in earlier times and lack of general education.
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.
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.
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).
You can't even run the current Xcode version on the previous macOS version, which is much more ridiculous, but that's the Apple software development ecosystem for you ;)
I also had this issue with a non-updatable MBP, but linux support is good, and I am looking forward to trying Zig out with Risc-V when I can get my hands on some hardware that hopefully wont expire as fast.
[+] [-] kristoff_it|2 years ago|reply
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/
[+] [-] bonzini|2 years ago|reply
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?
[+] [-] ksec|2 years ago|reply
[+] [-] AndyKelley|2 years ago|reply
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.
[+] [-] whitehexagon|2 years ago|reply
[+] [-] jedisct1|2 years ago|reply
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|2 years ago|reply
Is it mainly due to the zig's caching of the build artifacts?
[+] [-] quirino|2 years ago|reply
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)
[+] [-] ptato|2 years ago|reply
[+] [-] lionkor|2 years ago|reply
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).
[+] [-] acqq|2 years ago|reply
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
[+] [-] 2fast4you|2 years ago|reply
[+] [-] eggy|2 years ago|reply
[+] [-] hiccuphippo|2 years ago|reply
https://github.com/Not-Nik/raylib-zig
[+] [-] eru|2 years ago|reply
[+] [-] jmull|2 years ago|reply
Since it’s zig code, I think you would have that flexibility.
[+] [-] Hnus|2 years ago|reply
[+] [-] jcalabro|2 years ago|reply
https://github.com/vadimcn/codelldb
[+] [-] hiccuphippo|2 years ago|reply
[+] [-] flohofwoe|2 years ago|reply
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 :)
[+] [-] sciolistse|2 years ago|reply
[+] [-] duckqlz|2 years ago|reply
[+] [-] adelm|2 years ago|reply
[+] [-] flohofwoe|2 years ago|reply
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.
[+] [-] gavinhoward|2 years ago|reply
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.
[+] [-] pron|2 years ago|reply
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...
[+] [-] scrubs|2 years ago|reply
[+] [-] synergy20|2 years ago|reply
[+] [-] defen|2 years ago|reply
- All integer operations trap on overflow in safe build modes; with explicit operators for saturating or wrapping arithmetic
- No implicit integer promotion unless the destination type can represent all values of the source type (so no implicit signed/unsigned conversions unless they're statically guaranteed to be safe - e.g. a u8 can coerce to an i32 but not to an i8)
- Arbitrary bit-size integers (C23 will have this)
- Enums that are actually useful and fun, vs the complete waste of time that C's enums are (Enum values are namespaced, you can't directly use their values as integers, you can control the underlying representation if you want, etc)
- Built-in support for tagged unions, also known as sum types (bare union + a tag indicating which field is active)
- Safe unions in safe build modes (compiler inserts a hidden tag to track which field is active)
- A standard library that's actually useful (it's small compared to some other languages, and not well-documented yet, but it's not littered with landmines the way C's is)
- A modern import system instead of preprocessor-style copy/pasting text
- Compile-time programming in Zig, instead of preprocessor macros
- Arrays are an actual type, instead of decaying to pointers
- Much better support for pointers (pointer + length AKA slices are the primary way to deal with multiple items whose length can vary at runtime; also single-item pointers and multi-item pointers are different types, so you can't accidentally index into a single-item pointer or attempt to dereference a multi-item pointer without providing an index)
- Errors must be handled, with convenient syntax for passing the error up the stack + inferred error sets so that you don't have to explicitly annotate the set of possible errors for most functions
- Nulls encoded in the type system so that they must be explicitly handled.
- test blocks for writing tests inline and running them with `zig test`
[+] [-] tarruda|2 years ago|reply
- 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/
[+] [-] fileeditview|2 years ago|reply
He gives some examples of C vs Zig and what they tried to improve.
[+] [-] kristoff_it|2 years ago|reply
[+] [-] flohofwoe|2 years ago|reply
Reading this from top to bottom gives a pretty good overview:
https://ziglang.org/documentation/master/
[+] [-] Alifatisk|2 years ago|reply
[+] [-] dgb23|2 years ago|reply
Of course, Germans can speak and languages of German descent are just as rich, precise and expressive as any other. But the term Njemacki probably stuck around out of an initial ignorance about a foreign culture in earlier times and lack of general education.
[+] [-] flohofwoe|2 years ago|reply
[+] [-] mauricioc|2 years ago|reply
[+] [-] 64bittechie|2 years ago|reply
[deleted]
[+] [-] malkia|2 years ago|reply
[+] [-] rtkwe|2 years ago|reply
[+] [-] ksec|2 years ago|reply
[+] [-] klyrs|2 years ago|reply
[+] [-] winrid|2 years ago|reply
[+] [-] diimdeep|2 years ago|reply
[+] [-] kristoff_it|2 years ago|reply
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/
[+] [-] flohofwoe|2 years ago|reply
[+] [-] bbkane|2 years ago|reply
[+] [-] hiccuphippo|2 years ago|reply
[+] [-] whitehexagon|2 years ago|reply
https://ziglang.org/download/0.10.0/release-notes.html#Suppo...
I also had this issue with a non-updatable MBP, but linux support is good, and I am looking forward to trying Zig out with Risc-V when I can get my hands on some hardware that hopefully wont expire as fast.