Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is Zig so cool?

nilostolte.github.io

Post reply on HN
Print view View original

391–400 of 527 posts

Re: Why is Zig so cool?

#391

Post by scuff3d »

MrJohz wrote: post #97
qouteall wrote: post #70

In my opinion the biggest issue of Zig is that it doesn't allow attaching data to error. The error can only be passed via side channel, which is inconvenient and ENOURAGES TOOL DEVELOPERS TO NOT PASS ERROR DATA, which greatly increase debugging difficulty. Somethings there are 100 things that possibly go wrong. With error data you can easily know which exact thing is wrong. But with error code you just know "somethin…

Interestingly, I just read an article from matklad (who works a lot with Zig) talking about the benefits of splitting up error codes and error diagnostics, and the pattern of using a diagnostic sync to provide human-readable diagnostic information: https://matklad.github.io/2025/11/06/error-codes-for-control... Honestly I was quite convinced by that, because it kind of matches my own experiences that, even when using…

If they want to keep to the error/diagnostic pattern I think they're gonna have to adopt some kind of standard context object that gets passed around. Passing an allocator, an IO implementation, and a diagnostic object all over your code base is going to get really fucking old.

Re: Why is Zig so cool?

#392

Post by pjmlp »

wffurr wrote: post #387
pjmlp wrote: post #350

Earlier quoted context omitted.

Except Zig defaults could be found on the year of our Lord in 1976, 1978, 1983 and 1986. Exercise from other posts of mine which languages those might be.

Sure, but Zig is bringing those to users and making headlines on HN. I think that’s generally a good thing. Bringing the best of prior languages together in a new package

Except in 2025 we know better regarding safer systems programming languages, use after free is no longer something that we should tolerate.

Re: Why is Zig so cool?

#393

Post by tialaramex »

qouteall wrote: post #70

In my opinion the biggest issue of Zig is that it doesn't allow attaching data to error. The error can only be passed via side channel, which is inconvenient and ENOURAGES TOOL DEVELOPERS TO NOT PASS ERROR DATA, which greatly increase debugging difficulty. Somethings there are 100 things that possibly go wrong. With error data you can easily know which exact thing is wrong. But with error code you just know "somethin…

I agree, I like e.g. https://doc.rust-lang.org/std/string/struct.FromUtf8Error.ht...

See, we were trying to make this data we had into a string, Rust says all strings are UTF-8 encoded - but, turns out the data wasn't UTF-8 after all, here's an error with the data inside it.

Or a really delicate piece of design, (nightly for now) Vec::push_within_capacity. We're hoping the growable array (Vec) has enough space for this T, thus getting rid of it, but if not we don't want to grow the array, maybe we're bare metal software and can't afford to allocate on this hot path, so we get back an error with the T we were trying to push onto the array inside it, so we can do something else with that T but only when the problem happened, otherwise it's gone.

Re: Why is Zig so cool?

#394

Post by tamnd »

zobzu wrote: post #389
tamnd wrote: post #367

Earlier quoted context omitted.

Here is the link for you: https://github.com/little-book-of/c/blob/main/articles/zig-i... I hope next month I will have more time to write deep dives into the internals of SQLite, PostgreSQL, Redis and maybe curl, all written in C.

thanks, i enjoyed reading it (though a bit lengthy). what gets me personally is what you describe at https://github.com/little-book-of/c/blob/main/articles/zig-i... - zig is made to feel easy and modern for people who don't know any better, and it does this well. But as soon as you actually need to do complex stuff, it gets in the way moreso than C and it's current environment/ecosystem will. And to be fair, as much…

I mean, if you embed Zig in a larger C++, Rust, or Python project, coordinating the build systems can be difficult. Zig prefers to manage the entire pipeline itself, so mixing it with other compilers and dependency managers can require workarounds. In my opinion, the only practical way to do this is by exposing C interfaces.

Re: Why is Zig so cool?

#395

Post by pjmlp »

jb1991 wrote: post #339
pjmlp wrote: post #295

Earlier quoted context omitted.

Nah, that is what pedantic folks without English grammar knowledge keep complaining about, instead of actually discussing better security practices in both languages. It is a bikeshedding discussion that doesn't help in anything, regarding lack of security in C, or the legions of folks that keep using C data types in C++, including bare bones null terminated strings and plain arrays instead of collection types with b…

This has nothing to do with bikeshedding, it is a genuine misunderstanding of these two languages that is propagated in this way. This is not about grammar.

Yet those complaining usually make use of plenty C constructs, data types and standard library on their C++ projects, instead of modern C++ practices.

Re: Why is Zig so cool?

#396

Post by pjmlp »

1718627440 wrote: post #359
pjmlp wrote: post #328

Earlier quoted context omitted.

Proper C++ should use new , delete , custom allocators, and standard collection types. Even better, all heap allocations should be done via ownership types. Calling into malloc () is writing C in C++, and should only be used for backwards compatibility with existing C code. Additionally there is no requirement on the C++ standard that new and delete call into malloc() / free() , that is usually done as a matter of co…

> Calling into malloc () is writing C in C++, and should only be used for backwards compatibility And this is exactly the stance I am arguing against. C++ is not the newer version of C. It forked of at some point and is a quite different language now. One of the reasons I do use malloc for, is for compatibility with C. It is not for backward compatibility, because the C code is newer. In fact I actively change the co…

So it would fail to compile when configuring static analysis to build on error when using C with C++ compiler.

Finally, people like to argue between C and C++ when it convenient to do so, yet the compiler language switches to use C extensions in C++ mode keep being used across many projects.

Re: Why is Zig so cool?

#397

Post by tamnd »

zobzu wrote: post #389
tamnd wrote: post #367

Earlier quoted context omitted.

Here is the link for you: https://github.com/little-book-of/c/blob/main/articles/zig-i... I hope next month I will have more time to write deep dives into the internals of SQLite, PostgreSQL, Redis and maybe curl, all written in C.

thanks, i enjoyed reading it (though a bit lengthy). what gets me personally is what you describe at https://github.com/little-book-of/c/blob/main/articles/zig-i... - zig is made to feel easy and modern for people who don't know any better, and it does this well. But as soon as you actually need to do complex stuff, it gets in the way moreso than C and it's current environment/ecosystem will. And to be fair, as much…

And I want to clarify again, these are just personal notes written with some help from LLMs. They may contain mistakes, so please read them with curiosity, or feel free to skip them altogether.

Re: Why is Zig so cool?

#398

Post by smj-edison »

dns_snek wrote: post #226
qouteall wrote: post #70

In my opinion the biggest issue of Zig is that it doesn't allow attaching data to error. The error can only be passed via side channel, which is inconvenient and ENOURAGES TOOL DEVELOPERS TO NOT PASS ERROR DATA, which greatly increase debugging difficulty. Somethings there are 100 things that possibly go wrong. With error data you can easily know which exact thing is wrong. But with error code you just know "somethin…

Agreed, this is probably my biggest ongoing issue with Zig. I really enjoy it overall but this is a really big sticking point. I find it really amusing that we have a language that has built its brand around "only one obvious way to do things", "reducing the amount one must remember", and passing allocators around so that callers can control the most suitable memory allocation strategy. And yet in this language we su…

Genuine question, how would error set unioning work with payloads? error.WriterFailed (might be getting the exact name wrong) is returned from many different writers, whether writing to a statically allocated array, writing to a socket, or writing to a file. Each error would have a very different payload, so how would you disambiguate between the different payloads with a global error type? The way I see it is either you have error sets, or payloads, but not both.

Re: Why is Zig so cool?

#399

Post by pjmlp »

jb1991 wrote: post #338
pjmlp wrote: post #232

Earlier quoted context omitted.

Nope, that is a English grammar construct that is a shortcut for "and" and "or", as any good English grammar book will explain. Indeed you see those for Java/Scala and Objective-C/Swift in technical books and job adverts. Any search on the careers sites, or documentation, on companies that have seats at ISO, sell/develop C and C++ compilers, have such C/C++ references in a couple of places. Do you need any example?

Not in this context, that’s incorrect.

What context?

The pedantic folks that jump of their chair when seeing something all companies that pay WG21 salaries use on their docs?

If only they would advocate for writing safer code with the same energy, instead of discussing nonsense.

That is why C and C++ communities are looked down by security folks, and governments.

Re: Why is Zig so cool?

#400

Post by jorangreef »

metaltyphoon wrote: post #366
jorangreef wrote: post #21

Earlier quoted context omitted.

We could not have written TigerBeetle, at least not the way it is, without Zig: https://tigerbeetle.com/blog/2025-10-25-synadia-and-tigerbee...

Read that and what part of that can’t be done in Rust in 2025?

“done” or “done as well”?
Post reply on HN