Community blog where Zig programmers post tutorials and technical articles on topics like build systems, thread pools, and C interop.
HN commenters recommend it as a place to learn Zig, where many people write learning posts, alongside Ziglings and the official docs.
Hi, I'm Loris from the ZSF.
I think this is a fair post overall given what it is: a log of what it was like for one specific person to use Zig for AoC for the first time.
I'll spend some words on some of the things mentioned and then add some more useful advice for forrestthewoods at the end.
From my perspective the complaints mostly were about now knowing things which had varying degrees of discoverability.
The first point in Day 1 about mixing optionals and error unions is an example of something very easy to discover (by reading the language reference), so I personally would consider it an unlucky mistake by the author.
The second point (how to print an integer) is about something way less easily discoverable than in the previous example. You need to learn about how to print, then about `fmt` and from there the only authoritative place that contains information about format specifiers is the doc comment of `std.fmt.format`.
This second example is the kind of thing that we're the weakest at communicating to people because it's not a feature of the language itself (so it doesn't belong to the language reference) and, while you could in theory find this stuff in the stdlib autogenerated docs, you still have the problem of having to discover first what to search for. This is especially problematic when Zig breaks away from what's common in programming languages. One example of that is the fact that Zig has no print statement.
I've given some talks and written some…
It mainly comes down how the std is designed. Zig has many good building blocks like allocators, and how every function that allocates something takes one. This allows you to reuse the same code for different kind of situations.
Hash maps in zig std are another great example, where you can use adapter to completely change how the data is stored and accessed while keeping the same API [1]. For example to have map with limited memory bound that automatically truncates itself, in rust you need to either write completely new data structure for this or rely on someone's crate again (indexmap).
Errors in zig compose also better, in rust I find error handling really annoying. Anyhow makes it better for application development but you shouldn't use it if writing libraries.
When writing zig I always feel like I can reuse pieces of existing code by combining the building blocks at hand (including freestanding targets!). While in rust I always feel like you need go for the fully tailored solution with its own gotchas, which is ironic considering how many crates there are and how many crates projects depend on vs. typical zig projects that often don't depend on lots of stuff.
1: https://zig.news/andrewrk/how-to-use-hash-map-contexts-to-save-memory-when-doing-a-string-table-3l33
Ghostty is trying to be a speed demon terminal, so I'd expect it to use ReleaseFast.
The current build system docs don't prioritize one build mode over another:
https://ziglang.org/learn/build-system/
> Standard optimization options allow the person running zig build to select between Debug, ReleaseSafe, ReleaseFast, and ReleaseSmall. By default none of the release options are considered the preferable choice by the build script, and the user must make a decision in order to create a release build.
But for more opinionated recommendations, ReleaseSafe is clearly favored:
https://zig.news/kristoff/how-to-release-your-zig-applications-2h90
> ReleaseSafe should be considered the main mode to be used for releases: it applies optimizations but still maintains certain safety checks (eg overflow and array out of bound) that are absolutely worth the overhead when releasing software that deals with tricky sources of input (eg, the internet).
https://zighelp.org/chapter-3/
> Users are recommended to develop their software with runtime safety enabled, despite its small speed disadvantage.
If you could somehow collect real-world data, the overwhelming majority of Zig programs aren't released and have likely only made debug builds :P
> Building is slow. It takes about ~3 seconds minimum which is frustratingly slow when I'm fighting basic syntax errors. I wish there was a fast zig check.
> Lack of zig-analyzer makes learning hard.
> zig fmt src/main.zig is nice. Wish it automatically ran on all files.
I also did (well, "am doing", can only work a bit each day and am plugging through day 7 right now) AdventOfCode in Zig this year.
These points here didn't resonate with me at all. I wonder if the author knew about or tried ZLS[0]. I had it on and integrated with my VSCode and it would check a lot of things as I went and format on save. I think I followed something like this[1] to set it up.
[0] https://github.com/zigtools/zls
[1] https://zig.news/jarredsumner/setting-up-visual-studio-code-for-writing-zig-kcj
I have no dog in this race as I don't use Zig at the moment, but I'm not sure speculative is that unfair. Zig can literally be a drop-in replacement for GCC/clang [1], meaning you don't even have to fully adopt Zig as the build tool, so your initial comment about a lack of separation of concerns doesn't seem correct: just use "zig cc" for the C/C++ source if that's all you want.
That said, using Zig as the build tool seems to bring trivial cross-compilation support and portability, without having to deal with linkers [2]. Cross-compilation has always been and remains a PITA, so that's pretty compelling.
[1] https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html
[2] https://zig.news/kristoff/compile-a-c-c-project-with-zig-368j
Good article, the biggest paradigm shift for me thinking about ECS was also the bottom-up approach. I'm most intrigued by platforms and frameworks that automatically "ECS-ify" data structures, like Zig's MultiListArray [0]
As an aside, I was surprised that the author goes to Harvard yet his resume looks shockingly normal, not terribly different (in terms of software internships) than the people I went to school with. It's bizarre, given the fact that Harvard/YPSM admits are basically superhuman in every conceivable quality compared to the rest of us mortals.
[0]: https://zig.news/kristoff/struct-of-arrays-soa-in-zig-easy-in-userland-40m0