I really like Zig, but I do think you have to accept some rough edges and breaking changes when using it. Give it another decade and I am hopeful it will be much more stable.
This one is fairly minor, but the overly granular namespacing drives me nuts. I shouldn't have to go four or five layers deep to get fairly common functionality. The pattern of returning structs from within structs from within structs just gets old. Maybe that has to do with the way the language handles generics, I don't know.
The attitude to interfaces is also grating. I get that Kelly and the Zig team want to discourage there use, but with the changes to Io it feels a bit like they want to have their cake and eat it to. Before it was mainly just allocators, but now readers, writers, and it sounds like async are all going to be handled through interfaces. But yet the community writ large is still expected to not really use them. Seems like they should have sorted their attitude and approach to interfaces before making these most recent changes.
Yeah, I can see that. It's also difficult to put my finger on, but for a language that claims to be simple it seems to make a lot of things needlessly complicated. I'm also not loving how everything is deeply nested structs so I have to do struct.doThefirstThing.doTheSecondThing.doTheThirdThing().etc() all the time.
Perhaps you just feel that way because of 10+ years of accreted expectations?
To me, it feels like a reinvention of an interesting idea: Fastbufs
https://www.ucw.cz/libucw/doc/ucw/fastbuf.html
I will concede that the ergonomics of Io in Zig right now are pretty rough sledding.
One annoyance that I've ran into when using Zig as a transpiler backend is the lack of unstructured goto. Many languages don't need that, but if you're dealing with the one that does, converting such code is non-trivial.
Eventually, I restructured my IR to allow for more imperative code-generation, which I believe will lead to slightly better optimizations by the compiler.
I'm using it as a cross-compiler for linux-arm64 because its much simpler to download a single archive and extract it somewhere than to waste a bunch of time on guessing how each different Linux distro does ARM64 cross compilers (or doesn't in the case of Fedora).
The more Zig-the-language is hyped, the more I see it doesn't bring anything of interest. Zig-the-toolchain, on the other hand, is neat.
Does anyone know if it’s reasonably easy to use elf2 as a standalone linker in a c/c++ toolchain? Or is it specially built just for Zig?
https://github.com/jacobly0/zig/tree/4508c2543508e04253471e1... https://github.com/jacobly0/zig/blob/4508c2543508e04253471e1...
I might be mistaken, but the brief look at code shows that the speed up appears to come from combination of async architecture (the selling point of Mold) and intelligent usage of PUNCH_HOLE/INSERT_RANGE fallocate() operations.
Surprisingly enough PUNCH_HOLE and friends have already matured to be production ready, with viable support from ext4 and xfs filesystem. The possibilities!
No kidding. There are also https://github.com/davidlattimore/wild and https://github.com/kubkon/bold.
There are other projects that have used it in a similar way too.
[1] https://actually.fyi/posts/zig-makes-rust-cross-compilation-... [2] https://jcbhmr.com/2024/07/19/zig-cc-cmake/
My point was that Zig uses their backends (which includes their homegrown ones), but since `zig cc` is a wrapper around Clang, it always goes through the `LLVM` path and sidesteps the Zig backend(s).
