alt Hacker NewsZig is a nice language, but those articles always compare new languages against old-style C without use of modern tools. Most of the listed advantages you can have in C as well if you are willing to adopt modern tooling and style: signed overflow checking: sanitizers, errors you can not ignore: [[nodiscard]], slice type which know their size: variably-modified types or span types.
Defer will also appear in C compilers soon, but personally I still think goto-error handling is clearer.
(Rust has an advantage for temporal memory safety, but this does apply to Zig.)
Replies
IMO you cannot fairly compare static analyzers/sanitizers with features baked into the language/compiler.
Though I've noticed the same trend when reading a famous Rust primer for C++ developers. Like there are obviously so many good and valid arguments when comparing the two languages that would've gotten the point across. Yet the authors felt the need to push it one step further, where the comparison no longer seems fair. Like comparing Rust with C++17 when C++20 provides the same exact feature that Rust claims to provide.
Zig's tooling is very good, so is the cross-compatibility story and tagged unions.
But while you can have some/most of the benefits Zig has from modern C, I think an underrated benefit is the language culture. As a different language it was the opportunity for a reset, e.g. it's idiomatic Zig to pass allocators to functions, meaning every library in Zig will work this way.
You could do that in C, but none or very few libraries do that so whenever you reach out to third-party dependencies (which is not a lot, in C as in Zig) you have to fight against C's traditional patterns.
That works as long as you have zero dependencies.
As soon as you have dependencies you are dealing with however the authors decided to build things.
Part of why languages exist is just to get a new ecosystem.
At this point, you could fork C/C++, only remove features, give it a new name, a new package service, and maybe fork the standard library, and you could end up with something pretty competitive against Zig or Rust.
comptime instead of preprocessor macros is pretty big though…
I mostly agree, but as usual there are the classical catches:
1. yeah you can do that, but we should really do some (most? all?) of the things you mention (as well as other safeguards) mandatory
2. your code might be alright, but what about your dependencies ?
It seems that part of what Zig is trying to do, though, is create a pit of success around these practices. So the response might be something like, “Yes you can do these things in modern C, but doing it consistently requires more discipline than we’d like.”
https://blog.codinghorror.com/falling-into-the-pit-of-succes...