4 ms·

I've been working with Zig almost 8h/day since Sept. of last year[0], and am super excited about the ideas it is bringing to low-level programming - even to C/C

I've been working with Zig almost 8h/day since Sept. of last year[0], and am super excited about the ideas it is bringing to low-level programming - even to C/C++/Rust. I hope folks outside of the Zig community give it a glance even if just for the ideas it brings around cross-compilation and being a nice out-of-the-box experience. Some of my favorite highlights from this release: > With the advent of the Self-Hosted Linker, Zig is now able to generate well-formed and codesigned binaries on arm64 macOS (aka the Apple Silicon). It is also able to cross-compile C, C++, and Zig code to an arm64 and x86_64 macOS. Additionally, arm64 nightly binaries of Zig are automatically generated by our Continuous Integration service, meaning both arm64 and x86_64 macOS are now Tier 1 targets. From what I know, with existing cross-compilation for C/C++/Rust, code-signed MacOS binaries are not possible. This new Zig linker makes it possible and works for C/C++/Rust as well[1]. > Finally, as a side experiment, Jakub added in Zig Build System integration with Darling (#8760), a translation layer of macOS syscalls to Linux, with the intention of being able to cross test MachO binaries and macOS specific tests directly on Linux simply by passing in an additional flag -Denable-darling to zig build test. This line of thinking - not only "how do I cross-compile", but "how do I test my cross-compiled code?" is super interesting to me. I hope it is explored further. Finally, it's just incredibly cool to see how quickly Zig is developing and how financially stable it is[2], supporting handfuls of core team members to work on Zig. I haven't seen any other language community achieve this, let alone without corporate backing. Truly beautiful. [0] https://devlog.hexops.com/2021/increasing-my-contribution-to-zig-to-200-a-month https://devlog.hexops.com/2021/increasing-my-contribution-to... [1] https://www.reddit.com/r/rust/comments/nii64t/zig_makes_rust_crosscompilation_just_work/ https://www.reddit.com/r/rust/comments/nii64t/zig_makes_rust... [2] https://github.com/sponsors/ziglang https://github.com/sponsors/ziglang

lhorie 5y ago
Yeah, what's really compelling to me is how much effort zig puts on "plumbing" work as opposed to tacking more and more language features. It speaks volumes that zig can provide toolchain-level benefits to other low level languages like Rust.
bla3 5y ago
> code-signed MacOS binaries are not possible As far as I know, this is possible with clang and the new mach-o lld port as well. While it's possible with clang/lld in C++, it looks like it is much easier with zig.
tialaramex 5y ago
There is a Rust code-signing implementation. https://github.com/indygreg/PyOxidizer/tree/main/tugger-apple-codesign https://github.com/indygreg/PyOxidizer/tree/main/tugger-appl... Whether you should teach Rust to code-sign your software using this code is probably a tricky question, but it appears to me that you could.
lenkite 5y ago
I really, really wish Zig had RAII. I am so used to this in C++ and have grave difficulty living without it. But it has been shot down as RAII is considered a high-level feature. Well, I guess I will admire the language from a distance but I am unlikely to use it practically. https://github.com/ziglang/zig/issues/782 https://github.com/ziglang/zig/issues/782
- c0ast 5y ago
  With regards to RAII (as in constructors/destructors, not the stuff in the issue you linked), I think it simply didn't fit within Zig's goals. A big part of Zig is readability; what you read is what you get, and RAII is very much not that. Looking at a block of C++ code, there's no way to tell what happens unless you also know what the constructors/destructors of each data type in the block does.
  - PoignardAzur 5y ago
    I wonder if Zig could add a "mustbedestroyed" annotation to a type, that doesn't actually add RAII-style invisible code, but forces developers do add 'defer' instructions to code that creates instances of the type. EDIT: Aaand shockingly, I'm not the first to come up with this idea: https://github.com/ziglang/zig/issues/782 https://github.com/ziglang/zig/issues/782
  - lenkite 5y ago
    Destructors don't do any strange thing in C++ apart from closing allocated resources - so in reality you always know what happens. This presents mistakes and decreases code length in calling code.
  - adrusi 5y ago
    And more concretely, a language design rule of thumb in Zig is that if a function is called, there should be an explicit function call. Zig offers defer and errdefer as the closest substitute for RAII that makes all calls explicit.

lhorie 5y ago

Yeah, what's really compelling to me is how much effort zig puts on "plumbing" work as opposed to tacking more and more language features. It speaks volumes that zig can provide toolchain-level benefits to other low level languages like Rust.

bla3 5y ago

> code-signed MacOS binaries are not possible As far as I know, this is possible with clang and the new mach-o lld port as well. While it's possible with clang/lld in C++, it looks like it is much easier with zig.

tialaramex 5y ago

There is a Rust code-signing implementation. https://github.com/indygreg/PyOxidizer/tree/main/tugger-apple-codesign https://github.com/indygreg/PyOxidizer/tree/main/tugger-appl... Whether you should teach Rust to code-sign your software using this code is probably a tricky question, but it appears to me that you could.

lenkite 5y ago

I really, really wish Zig had RAII. I am so used to this in C++ and have grave difficulty living without it. But it has been shot down as RAII is considered a high-level feature. Well, I guess I will admire the language from a distance but I am unlikely to use it practically. https://github.com/ziglang/zig/issues/782 https://github.com/ziglang/zig/issues/782

c0ast 5y ago
With regards to RAII (as in constructors/destructors, not the stuff in the issue you linked), I think it simply didn't fit within Zig's goals. A big part of Zig is readability; what you read is what you get, and RAII is very much not that. Looking at a block of C++ code, there's no way to tell what happens unless you also know what the constructors/destructors of each data type in the block does.
- PoignardAzur 5y ago
  I wonder if Zig could add a "mustbedestroyed" annotation to a type, that doesn't actually add RAII-style invisible code, but forces developers do add 'defer' instructions to code that creates instances of the type. EDIT: Aaand shockingly, I'm not the first to come up with this idea: https://github.com/ziglang/zig/issues/782 https://github.com/ziglang/zig/issues/782
- lenkite 5y ago
  Destructors don't do any strange thing in C++ apart from closing allocated resources - so in reality you always know what happens. This presents mistakes and decreases code length in calling code.
- adrusi 5y ago
  And more concretely, a language design rule of thumb in Zig is that if a function is called, there should be an explicit function call. Zig offers defer and errdefer as the closest substitute for RAII that makes all calls explicit.