Hacker News new | ask | show | jobs
by johnisgood 2456 days ago
I might be alone with this thought: Zig seemed really appealing in the beginning, but now I dislike it more and more with each release. It does not seem to keep the simplicity of C at all, it has lots of peculiarities, and it is becoming more and more bloated. I would consider it a C++ replacement at this point, not a C replacement due to its increasing complexity. One of Zig's philosophy was simplicity[1], but I do not think it applies now.

[1] https://github.com/ziglang/zig/wiki/Why-Zig-When-There-is-Al...

3 comments

I do get the feeling, but I think part of it is simply that those of us that are used to C tend to underestimate its complexity. Especially when you consider various extensions which are widely used, the preprocessor magic often needed to perform essential tasks, and all the undefined behaviour.

There is really only one thing that I would say goes beyond keeping the language simple as possible: the async stuff. But I think it will probably be totally worth it. The async implementation looks a lot more elegant than anything I've seen so far, and it could be extremely useful in the embedded world, which is one of the places where C is dominant. It might make the language a bit more complicated, but it will make the resulting code much more simpler for a lot of applications, without compromising other goals like safety and efficiency.

Zig is still much, much closer to C than C++. If you don't think so, then you're vastly underestimating the complexity of C++.

Can you give examples of the peculiarities? I write cpp all day and zig is a nice change for me because of how simple it is to me
> Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integers in C

make a feature unwanted in C, worse. nice.

debug and safe modes in zig disallow overflows entirely unless you specifically use the wrapping operator to clearly specify your intent. These checks are removed in speed-optimized builds.

In other words, the compiler will enforce that `a + b` does not overflow through all your testing and wherever you explicitly say such checks are required, but turns them into nops for you when you desire speed. You can let the compiler know that you explicitly want wrapping overflow (and not some undefined kind) using the wrapping operator `a +% b`.

It's actually become simpler and slimmer, with fewer peculiarities!
Could you follow up with some examples? Seems to contradict the parent but neither comment provides examples.
They got rid of the % operator for error propagation for one.
That's funny; one selling point of rust is the easy propagation of errors thanks to the '?' but zig removed the % which was the equivalent I think
The operator wasn't removed, it was replaced by a keyword. See the documentation on error handling: https://ziglang.org/documentation/master/#catch
You can still propagate errors in zig using ? like in rust. they just simplified it