Several years ago I was very exited about Zig programming language and made a bold statement:
> Unless you care about portability, I see no reason to write C since now I can write Zig.
I still don't care about portability to anything other than linux-x86_64, but there are reasons to write C after all.
In October 2024 I wrote a small (~600 lines) program in Zig that formatted YAML files in some $dayjob-specific way. Instead of parsing the whole document, the program linked to libyaml tokenizer and operated on tokens, which ended up factor 10 faster than pyyaml.load/pyyaml.dump implementation. Success, right?
https://pyyaml.org/wiki/LibYAML
https://pyyaml.org/wiki/PyYAMLDocumentation
Ever since, upgrade of nixpkgs pin, which happens twice a year, is more painful that I would like it be. Since zig=0.11, there was var/const transition, changes to build.zig, move of stuff from std.os to std.posix, and I am only on zig=0.13 now. I prefer to not think about upgrade to zig=0.15 with its massive rework of standard library.
I must stress that it is my own damn fault. Back in 2024 there was a prominent warning on the Zig's website saying something along these lines:
> If you are using Zig in production, you will have to participate in Zig's development.
It would probably took me twice as long to achieve the same functionality and performance in C, so hours-wise it is roughly net zero, but having to spend time maintaining a program that I consider finished is frustrating: I solved a problem, moved on and feel entitled that the problem stays solved.
This is something I didn't consider before. Will the software ever be done, or is it inherently ever-changing? The answer affects the choice of the most suitable tool for the job.