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.
> 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.
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.
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.
Re:Zig 0.8.0 Release Notes
by PoignardAzur on Saturday June 05, 2021 @06:33AM
(#27403796)
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
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.
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.
Re:Zig 0.8.0 Release Notes
by tialaramex on Friday June 04, 2021 @08:48PM
(#27400874)
There is a Rust code-signing implementation.
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.
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...
[1] https://www.reddit.com/r/rust/comments/nii64t/zig_makes_rust...
[2] https://github.com/sponsors/ziglang