7 ms·

- No preprocessor nonsense - typesafe metaprogramming (usually no void* type erasure) - sane legibility of complicated types - (for beginners) not having to

- No preprocessor nonsense - typesafe metaprogramming (usually no void* type erasure) - sane legibility of complicated types - (for beginners) not having to learn/deal with make - corrects the long long mistake (yes, I get that everyone uses inttypes.h now) - alignment aware pointer types - null aware pointer types - null terminated string aware pointer types - slices (fat pointers?) default - sane cross-compilation - errors returned as values, no errno weirdness - no pass-by-value/pass-by-reference ambiguity (const correctness by default) At least four of these are footguns my highly experienced coworkers would have avoided this last week of work alone. It's possible that as a longtime c developer, you have internalized the biggest problems with c, especially the ones that trip up beginners. Maybe zig is not for you. If you start using zig, you just may start wanting to throw your desk out the window every time you have to go back to c, which is not really worth the effort/employmemt sanity risk.

lgkk 3y ago
Is make considered bad or something? I use make and I mostly program in Go. It seems to make my life pretty simple. What is an alternative?
- dureuill 3y ago
  > Is make considered bad or something? Depends what you're using it for. Generated from CMake, Makefiles are OK I guess, although Ninja is strictly better these days. Manually written, I would say make is bad. 1. It doesn't promote portability: since each target calls shell commands, it is very easy to accidentally create a non portable Makefile (something alleviated when using CMake that handles the portability before emitting the Makefile) 2. It is imperative and stateful in subtle ways, which is the wrong level of abstraction for a build system. Systems that are declarative and describe the desired state of the build are much easier to use and reliable 3. It is bare bone as far as build system functionality goes: it doesn't provide many of the useful things I expect from a modern build system: the concepts of library dependencies, build profiles, compiler flags, test, documentation or even project in general... are all orthogonal to make 4. It is ad-hoc: as a result of the previous points, the expected functionality of a build system is often re-created in the makefile, but in a non fully standard way (conventions exist, but must be manually enforced and are limited). This results in brittle and difficult to use build systems. > What is an alternative Language-specific package managers, notably Cargo. If using rust, there's also a pattern called xtask[1] that's aiming at providing a standard interface in the form of a binary (since it is rust, it is portable, but most of the other points unfortunately apply). Otherwise, CMake, meson, nix, bazel, buck2 [1]: https://github.com/matklad/cargo-xtask https://github.com/matklad/cargo-xtask
  - lgkk 3y ago
    Cool! What would you suggest for go? Fwiw I develop on a Ubuntu workstation. I build and deploy to mostly Ubuntu or bare bones Linux.
- throwawaymaths 3y ago
  > It seems to make my life pretty simple. Presuming you're doing anything more than the bog-simple "check age of file, maybe compile, maybe link": How does it make the life of someone who has to read or debug your code?
deleted 3y ago
[deleted]
flohofwoe 3y ago
> No preprocessor nonsense Yet still the C preprocessor can do things that are not possible in Zig. Just because it is a simple text replacement tool doesn't mean it's 'nonsense'.
- kaba0 3y ago
  Sure - it is worse than nonsense. It can do stuff like non-compiling code and hard to find bugs.
throwawaymaths 3y ago
Man the more I think about it there are even more: typedef NAME struct {}; vs struct {} NAME; (Did I even get that right?) - Namespacing in c is a nightmare, and c++ mangling is nuts. - sane way of importing code, no header/code bifurcation
synergy20 3y ago
those are good points, thanks! hope it will eventually include a http server and ssl into std for 1.0 release since many applications are now networked together. I will wait for 1.0 to try it again.
- throwawaymaths 3y ago
  The team is deliberately pushing back 1.0, they really want 1.0 to be as best possible a finalized version of the language they are happy with. You may be waiting for a long time. You should also know that the way you're engaging seems very concern-troll-ey. Why do I say that? > hope it will eventually include a http server and ssl into std for 1.0 Would you consider holding C to that standard? Like zig already has way more stuff in its std than c, including json support and crypto primitives.
  - synergy20 3y ago
    daily job is all c and c++ and Zig is something I need find time to get good at weekends and nothing critical for immediate needs, but yes I'm interested.
loeg 3y ago
Many of these are improvements on C++, too. Zig is pretty compelling in the space.
- throwawaymaths 3y ago
  C++ has all of these warts too as it's roughly speaking a superset of c. Yes I'm aware it's not an exact superset. I think you can get tripped up by all these things I have listed in c++.
beltsazar 3y ago
Why shouldn't the unexperienced systems programmers go "all in" by using Rust, then? The first priority for them should be memory safety. Not to mention that Rust has more ergonomic features and stronger ecosystems.
- throwawaymaths 3y ago
  Why should the first priority be memory safety? If the first priority is always memory safety, then rust should not have `unsafe` keyword. Existence of `unsafe` implies that, even rust, something is more important than safety And, maybe rust is a poor choice because the language encourages layering hidden complexity and architecture astronauting.
  - dureuill 3y ago
    Because gov agencies say so? Also, memory safety vulnerabilities is the largest class of vulnerability by count today by a large margin (70% of the total) and cost a lot of money to bigger companies. As changing language stacks also cost a lot of money, there needs to be a strong incentive to do so. Getting memory safety without compromising applicability to the lowest levels of the stack is one such incentive. Rust also doesn't have a lot of drawbacks, from my experience (professional use for years, coming from C++) and from recent reports from Google[1] (in particular, the learning curve steepness[2] and productivity penalty[3] are overstated). [1]: https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html https://opensource.googleblog.com/2023/06/rust-fact-vs-ficti... [2]: Anecdotally, these ramp-up numbers are in line with the time we’ve seen for developers to adopt other languages, both inside and outside of Google. (Same report) [3]: Overall, we’ve seen no data to indicate that there is any productivity penalty for Rust relative to any other language these developers previously used at Google. (Same report)
  - SkiFire13 3y ago
    > If the first priority is always memory safety, then rust should not have `unsafe` keyword. You can't have a system programming language without some unsafe layer because eventually you will have to interface with either the OS or a library written in another language and that's unsafe. Even languages like Java and C# have unsafe escape hatches for situations like these.
throwaway17_17 3y ago
I’m struggling with your assertion that Zig’s meta-programming is ‘typesafe’. I am very aware of its benefits compared to C’s ‘preprocessor nonsense’ (i.e. textual replacement ‘macros’), but I don’t think the normal definition of type safety covers how Zig’s meta-programming functions (I am assuming you’re talking about comptime and using Type arguments for things like generics). I am certainly able to understand how comptime expressions look well typed and safe compared to C, but, AFAIK, Zig’s comptime expressions are on par with C++ templates in Type Theory terms. Big caveat here being, I don’t see anything wrong with the implementations of this sort of meta-programming in Zig. It is in some ways analogous to the difference between static and dynamic typing, there is a PCWalton tweet explaining his view on this somewhere [1], particular regarding generics across languages. And while I take a different stance on the issue, I do think the tweet is a decent example. Zig’s meta-programming works well and errors will be caught during compilation at some point, I just don’t think it meets the technical (probably academic-centric) definition of type safety. I think it would take a comparison to something like Template Haskell to actually find type safe macros (MetaML came say earlier, but is not very well known). — I’m certainly open to being wrong about this from a technical standpoint, so feel free to disagree and maybe direct me to better/clearer documentation. 1 — https://twitter.com/pcwalton/status/1369101878642941953 https://twitter.com/pcwalton/status/1369101878642941953 :: There is a follow up tweet using more academic terms in a Type Theoretic setting, but I couldn’t find it quickly on mobile
- throwawaymaths 3y ago
  Yes for typesafe generics I mean "equivalent to template <T> in c++" For sure there are type-uhdsaff generics in zig. Allocator is probably the biggest example.
laserbeam 3y ago
> no pass-by-value/pass-by-reference ambiguity There's a known design issue [1] with one feature in zig that can cause issues with value/pointer passing and can cause aliasing errors. The goal for the language is to resolve the problem before 1.0, even though the fix will likely cause code to feel a bit closer to C. There's a talk [2] that goes into details on why this is an issue. Regardless, I still love zig. [1] https://github.com/ziglang/zig/issues/12064 https://github.com/ziglang/zig/issues/12064 [2] https://youtu.be/dEIsJPpCZYg https://youtu.be/dEIsJPpCZYg
- kibibu 3y ago
  Hmm, there's a distinct change of opinion by andrewrk from the linked issue (2022) to now https://github.com/ziglang/zig/issues/12064 https://github.com/ziglang/zig/issues/12064 (July 2022): > Hope you don't mind I'm going to reopen this issue because it concisely demonstrates a design flaw with result location semantics and I'm not ready to accept status quo as permanent due to aliasing issues like this. Compare to a very closely related issue regarding destructing, which exhibits the same problem https://github.com/ziglang/zig/issues/17283 https://github.com/ziglang/zig/issues/17283 September 2023): > This is working as designed. Everybody was aware this behavior would be a consequence of destructuring and there is no plan to change it.

lgkk 3y ago

Is make considered bad or something? I use make and I mostly program in Go. It seems to make my life pretty simple. What is an alternative?

dureuill 3y ago
> Is make considered bad or something? Depends what you're using it for. Generated from CMake, Makefiles are OK I guess, although Ninja is strictly better these days. Manually written, I would say make is bad. 1. It doesn't promote portability: since each target calls shell commands, it is very easy to accidentally create a non portable Makefile (something alleviated when using CMake that handles the portability before emitting the Makefile) 2. It is imperative and stateful in subtle ways, which is the wrong level of abstraction for a build system. Systems that are declarative and describe the desired state of the build are much easier to use and reliable 3. It is bare bone as far as build system functionality goes: it doesn't provide many of the useful things I expect from a modern build system: the concepts of library dependencies, build profiles, compiler flags, test, documentation or even project in general... are all orthogonal to make 4. It is ad-hoc: as a result of the previous points, the expected functionality of a build system is often re-created in the makefile, but in a non fully standard way (conventions exist, but must be manually enforced and are limited). This results in brittle and difficult to use build systems. > What is an alternative Language-specific package managers, notably Cargo. If using rust, there's also a pattern called xtask[1] that's aiming at providing a standard interface in the form of a binary (since it is rust, it is portable, but most of the other points unfortunately apply). Otherwise, CMake, meson, nix, bazel, buck2 [1]: https://github.com/matklad/cargo-xtask https://github.com/matklad/cargo-xtask
- lgkk 3y ago
  Cool! What would you suggest for go? Fwiw I develop on a Ubuntu workstation. I build and deploy to mostly Ubuntu or bare bones Linux.
throwawaymaths 3y ago
> It seems to make my life pretty simple. Presuming you're doing anything more than the bog-simple "check age of file, maybe compile, maybe link": How does it make the life of someone who has to read or debug your code?

deleted 3y ago

[deleted]

flohofwoe 3y ago

> No preprocessor nonsense Yet still the C preprocessor can do things that are not possible in Zig. Just because it is a simple text replacement tool doesn't mean it's 'nonsense'.

kaba0 3y ago
Sure - it is worse than nonsense. It can do stuff like non-compiling code and hard to find bugs.

throwawaymaths 3y ago

Man the more I think about it there are even more: typedef NAME struct {}; vs struct {} NAME; (Did I even get that right?) - Namespacing in c is a nightmare, and c++ mangling is nuts. - sane way of importing code, no header/code bifurcation

synergy20 3y ago

those are good points, thanks! hope it will eventually include a http server and ssl into std for 1.0 release since many applications are now networked together. I will wait for 1.0 to try it again.

throwawaymaths 3y ago
The team is deliberately pushing back 1.0, they really want 1.0 to be as best possible a finalized version of the language they are happy with. You may be waiting for a long time. You should also know that the way you're engaging seems very concern-troll-ey. Why do I say that? > hope it will eventually include a http server and ssl into std for 1.0 Would you consider holding C to that standard? Like zig already has way more stuff in its std than c, including json support and crypto primitives.
- synergy20 3y ago
  daily job is all c and c++ and Zig is something I need find time to get good at weekends and nothing critical for immediate needs, but yes I'm interested.

loeg 3y ago

Many of these are improvements on C++, too. Zig is pretty compelling in the space.

throwawaymaths 3y ago
C++ has all of these warts too as it's roughly speaking a superset of c. Yes I'm aware it's not an exact superset. I think you can get tripped up by all these things I have listed in c++.

beltsazar 3y ago

Why shouldn't the unexperienced systems programmers go "all in" by using Rust, then? The first priority for them should be memory safety. Not to mention that Rust has more ergonomic features and stronger ecosystems.

throwawaymaths 3y ago
Why should the first priority be memory safety? If the first priority is always memory safety, then rust should not have `unsafe` keyword. Existence of `unsafe` implies that, even rust, something is more important than safety And, maybe rust is a poor choice because the language encourages layering hidden complexity and architecture astronauting.
- dureuill 3y ago
  Because gov agencies say so? Also, memory safety vulnerabilities is the largest class of vulnerability by count today by a large margin (70% of the total) and cost a lot of money to bigger companies. As changing language stacks also cost a lot of money, there needs to be a strong incentive to do so. Getting memory safety without compromising applicability to the lowest levels of the stack is one such incentive. Rust also doesn't have a lot of drawbacks, from my experience (professional use for years, coming from C++) and from recent reports from Google[1] (in particular, the learning curve steepness[2] and productivity penalty[3] are overstated). [1]: https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html https://opensource.googleblog.com/2023/06/rust-fact-vs-ficti... [2]: Anecdotally, these ramp-up numbers are in line with the time we’ve seen for developers to adopt other languages, both inside and outside of Google. (Same report) [3]: Overall, we’ve seen no data to indicate that there is any productivity penalty for Rust relative to any other language these developers previously used at Google. (Same report)
- SkiFire13 3y ago
  > If the first priority is always memory safety, then rust should not have `unsafe` keyword. You can't have a system programming language without some unsafe layer because eventually you will have to interface with either the OS or a library written in another language and that's unsafe. Even languages like Java and C# have unsafe escape hatches for situations like these.

throwaway17_17 3y ago

I’m struggling with your assertion that Zig’s meta-programming is ‘typesafe’. I am very aware of its benefits compared to C’s ‘preprocessor nonsense’ (i.e. textual replacement ‘macros’), but I don’t think the normal definition of type safety covers how Zig’s meta-programming functions (I am assuming you’re talking about comptime and using Type arguments for things like generics). I am certainly able to understand how comptime expressions look well typed and safe compared to C, but, AFAIK, Zig’s comptime expressions are on par with C++ templates in Type Theory terms. Big caveat here being, I don’t see anything wrong with the implementations of this sort of meta-programming in Zig. It is in some ways analogous to the difference between static and dynamic typing, there is a PCWalton tweet explaining his view on this somewhere [1], particular regarding generics across languages. And while I take a different stance on the issue, I do think the tweet is a decent example. Zig’s meta-programming works well and errors will be caught during compilation at some point, I just don’t think it meets the technical (probably academic-centric) definition of type safety. I think it would take a comparison to something like Template Haskell to actually find type safe macros (MetaML came say earlier, but is not very well known). — I’m certainly open to being wrong about this from a technical standpoint, so feel free to disagree and maybe direct me to better/clearer documentation. 1 — https://twitter.com/pcwalton/status/1369101878642941953 https://twitter.com/pcwalton/status/1369101878642941953 :: There is a follow up tweet using more academic terms in a Type Theoretic setting, but I couldn’t find it quickly on mobile

throwawaymaths 3y ago
Yes for typesafe generics I mean "equivalent to template <T> in c++" For sure there are type-uhdsaff generics in zig. Allocator is probably the biggest example.

laserbeam 3y ago

> no pass-by-value/pass-by-reference ambiguity There's a known design issue [1] with one feature in zig that can cause issues with value/pointer passing and can cause aliasing errors. The goal for the language is to resolve the problem before 1.0, even though the fix will likely cause code to feel a bit closer to C. There's a talk [2] that goes into details on why this is an issue. Regardless, I still love zig. [1] https://github.com/ziglang/zig/issues/12064 https://github.com/ziglang/zig/issues/12064 [2] https://youtu.be/dEIsJPpCZYg https://youtu.be/dEIsJPpCZYg

kibibu 3y ago
Hmm, there's a distinct change of opinion by andrewrk from the linked issue (2022) to now https://github.com/ziglang/zig/issues/12064 https://github.com/ziglang/zig/issues/12064 (July 2022): > Hope you don't mind I'm going to reopen this issue because it concisely demonstrates a design flaw with result location semantics and I'm not ready to accept status quo as permanent due to aliasing issues like this. Compare to a very closely related issue regarding destructing, which exhibits the same problem https://github.com/ziglang/zig/issues/17283 https://github.com/ziglang/zig/issues/17283 September 2023): > This is working as designed. Everybody was aware this behavior would be a consequence of destructuring and there is no plan to change it.