It's a blog post hosted on zig.news (so intended for an audience that knows Zig), I think we can safely assume that it's not meant to be an universal guide for understanding C code, but rather the recount of a (somewhat minor) experience lived by the author. It's even stated upfront:
> @rep_stosq_void on Twitter posted this strange sample of C code, and I wanted to show my process of understanding this contrived C code.
"I was presented with this code, and this is what I did to understand it"
I've happened to have written a lot of C, but some areas (like this one) I'm not as confident in. This way of casting, and working with types is very poor syntax in my opinion (I mean below in this thread you have people arguing about the spiral rule and such, it's obviously a common confusion).
Zig's way of expressing types and pointers is far superior, these transformations I made were done quickly and I didn't feel like there was any ambiguity or confusion in anything. Just a series of simple reductions, there are no "tricks" or easy mistakes to make in the code. It feels like a trivial proof.
Obviously I am biased, this was posted to zig.news. I thought it was a neat showcase of translate-c, and how zig does some of these things nicer. I'm not telling everyone that they should do what I did, but this works for me and I'm happy to share.
There is if you intend to use libraries as those libraries may well have chosen a build system other than the one you have chosen meaning you'd have to rewrite their build scripts. This is far from the experience of using libraries in languages with unified build systems which is typically as simple as adding a line with the version of the library you want to a manifest file.
So? I'm talking about the C experience, not the C standard.
And I criticize Zig for trying to be another kitchen sink (despite having no macros or preprocessor).
Removing a whole secondary language for macros actually just makes the language simpler
Main thing is that all these hip new languages will be dead in a couple years because they don’t do anything all that innovative. Making “another C” or “another C target” versus Go which focuses on channels, slices, and go routines. These other languages that “make a better X” simply will be sidelined in production deployments because no matter the language there will always be warts.
Really folks keep reinventing the wart in the name of something “better”.
> head-strong nerds inventing things
Let people have their fun.
> preprocessor allows you to add some logic before compilation
Zig's comptime feature does address that need. For most use cases where comptime and the preprocessor would both suffice, comptime has tons of strong advantages (type checked, errors traced back to the right lines, ability to write arbitrary turing-complete code without unholy syntactic black magic, no double evaluation, no need to wrap everything in extra parentheses, ....). It explicitly does not address use cases where you would actually want a textual preprocessor (like making the language look like Fortran), the argument being that the burden on reading unfamiliar code would be too high. The ease with which you can write arbitrary comptime code also enables you to do things like embed lookup tables in the binary, which in C you would ordinarily do by copy pasting from another tool (or writing constants by hand) or adding yet another preprocessor to the mix.
Comptime isn't a clear win over preprocessing in all cases, but having written a lot of C and a little Zig, if I had to choose one for a hypothetical new project I'd be tempted to use Zig just for access to that one feature.
> Syntax
Zig does feel a little clunky to write to me right now, but I think that's mainly do to how often I'm using @someBuiltin() in Zig when I would be using an operator or an additional language feature in something like Python.
That said, the syntax itself is incredibly simple. You can check that yourself for Zig [0], Python [1], and Go [2]. Zig has far fewer syntactic quirks and abilities than either of the other two. You have functions, operators, code blocks, types, reserved characters/keywords for builtin stuff, a few kinds of literals, and a little bit of syntactic sugar for working with structs.
> Don't reinvent C++...for instance, I even consider C better than Zig just because the features are small and knowable
To each their own. FWIW, Zig is explicitly and actively avoiding becoming a kitchen sink language like Rust or C++. They've added a few new features, and I personally find it easier to keep track of those than of all the different kinds of undefined behavior I might stumble across in C, especially since most of those (defer, errdefer, labeled break, ...) behave exactly as your intuition suggests they would.
[0] https://ziglang.org/documentation/master/#Grammar
void f(int * a)
{
void * p = reinterpret_cast<void *>(&a);
***reinterpret_cast<int *(*)[]>(p) = 1;
}(not sure what steps that should be)