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

241–250 of 527 posts

Re: Why is Zig so cool?

#241

Post by IshKebab »

johnisgood wrote: post #185
the__alchemist wrote: post #41

Earlier quoted context omitted.

For anyone not familiar: You can bundle arbitrary software as Python wheels. Can be convenient in cases like this!

What "cases" are those? Tell me one useful and neat case. Why is it useful and neat, you think?

It's useful as a distro-agnostic distribution method. CMake is also installable like this despite having nothing to do with Python.

Or I should say it was useful as a distribution method, because most people had Python already available. Since most distros now don't allow you to install stuff outside a venv you need uv to install things (via `uv tool install`) and we're not yet at the point where most people already have uv installed.

Re: Why is Zig so cool?

#242

Post by 59nadir »

qouteall wrote: post #127
jandrewrogers wrote: post #82

Earlier quoted context omitted.

The "correct" way is highly context dependent with the added proviso that Zig assumes a low-level systems context. In this context, adding data to an error may be expedient but 1) it has a non-trivial overhead on average and 2) may be inadvisable in some circumstances due to system state. I haven't written any systems in Zig yet but in low-level high-performance C++20 code bases we basically do the same thing when it…

If the error rarely happens then passing error data shouldn't affect performance in visible way. If the error occurs in common path then it's designed wrongly. I agree that in special states like OOM passing error data with allocation is not ok.

Error data being returned instead of just error codes doesn't require allocation at all, and never would, unless the specific unions that you're returning require as much. Zig already has tagged unions with a tag field and associated payload, that is exactly what you would return. The overhead isn't remarkably worse than the cost of modifying the value someone passed in to "Fill this in in case of errors" (which is what you have to do now in Zig).

Re: Why is Zig so cool?

#243

Post by flohofwoe »

johnisgood wrote: post #189
phplovesong wrote: post #112

Earlier quoted context omitted.

Agreed. But i would not put comptime as some sort of magical invention. Its still just a newish take on meta programming. We had that since forever. From my minimal time with Zig i kind of think comptime as a better version of c++ templates. That said Zig is possibly a better alternative to c++, but not that exiting for me. I kind of dont get why so many think its the holy grail, first it was rust, and now zig.

As much as I dislike Rust, I gotta give it credit where it's due. It has something unique: a borrow checker. What is so unique in Zig?

> It has something unique: a borrow checker.

Rust's borrow checker isn't unique either but was inspired by Cylone: https://en.wikipedia.org/wiki/Cyclone_(programming_language)

IMHO a programming language doesn't need a single USP, it just needs to include good existing ideas and (more importantly) exclude bad existing ideas (of course what's actually a good and bad idea is highly subjective, that's why we need many programming languages, not few).

Re: Why is Zig so cool?

#244

Post by dgrunwald »

mirsadm wrote: post #212
reorder9695 wrote: post #173

Earlier quoted context omitted.

Rust's solution to this is quite good, that's 0..9 and if you want to include 9 it's 0..=9, it looks a bit funny but knowing one with an = sign in it exists removes any doubt

Adding additional syntax to a language for this case seems bonkers to me. People can just write 0..10.

If you need `0..=n`, you can't write `0..(n+1)` because that addition might overflow.

Re: Why is Zig so cool?

#245

Post by 59nadir »

qouteall wrote: post #71
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 know that Zig doesn't allow attaching data to error for valid reasons. If error data contains interior pointer then it can easily cause memory safety problem. Zig doesn't have a borrow cheker or ownership system to prevent that. https://github.com/ziglang/zig/issues/2647#issuecomment-2670...

If you wanted to have a parameter that gets filled in when there is an error, this exact issue will remain, it's completely unrelated to which language construct you use to capture errors and has more to do with having a good idea of how your errors are allocated, if they require allocation. I don't think the commenter in the GitHub issue thought this through at all, and probably didn't expect to have it be held up as some example of why you can't return tagged unions (because it's not an example of that, not even remotely).

Re: Why is Zig so cool?

#246

Post by 59nadir »

brabel wrote: post #197
andai wrote: post #34

Earlier quoted context omitted.

+1 for Odin. I wrote a little game in it last year and found it delightful.

I prefer Odin to Zig after trying both... but it seems Odin's performance is a bit lower than Zig, C and Rust?! Have you noticed any performance issues or it's not something to worry about?

No, I write Odin for production and there is no performance difference to speak of coming from the way the compiler or language works. If you have one it's likely because of an older/different LLVM version being used, but AFAIK Odin stays as up-to-date as you can without tearing your hair out (and that's good because GingerBill has none of that to spare).

There might be a few pathological code paths in the core libraries or whatever for certain things that aren't what they should be, but in terms of the raw language you're in the land of C as much as with any of these languages; Odin really doesn't do much on top of C, and what it's doing is identifiable and can be opted out of; if you find that a function in a hot loop is marginally slower than it ought to be, you can make it contextless, for example, and see whether that makes a difference.

We haven't found (in a product where performance is explicitly a feature, also containing a custom 3D engine on top of that) that the context being passed automatically in Odin is of much concern performance-wise.

Out of the languages mentioned Rust is the one I've seen in benchmarks be routinely marginally slower, but it's not by a meaningful amount.

Re: Why is Zig so cool?

#247

Post by Galanwe »

pyrolistical wrote: post #147
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 can see pros and cons. Preventing data being attached to an error forces more clear and precise errors. Whereas lazy devs could just attach all possible data in a giant generic error if they don’t want to think about it.

> Preventing data being attached to an error forces more clear and precise errors.

Okay maybe theorically, but in the real world I would like to have the filename on a "file not found", an address on a "connection timeout", a retry count on a "too many failures", etc.

Re: Why is Zig so cool?

#248

Post by hgomersall »

dgrunwald wrote: post #244
mirsadm wrote: post #212

Earlier quoted context omitted.

Adding additional syntax to a language for this case seems bonkers to me. People can just write 0..10.

If you need `0..=n`, you can't write `0..(n+1)` because that addition might overflow.

I'm actually curious now how this is stored on `Range` in rust. I've certainly used ..= for exactly the reason you say, but as far as I'm aware `.end` on the range is the exclusive upper bound in all cases. What happens to `.end` in the overflowing case?

Edit: it doesn't use Range for ..=, but rather RangeInclusive, which works fine.

Re: Why is Zig so cool?

#249

Post by recursivetree »

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…

Having metadata with the error doesn't exclude having a separate diagnostics system. You don't have to use errors with metadata.

Re: Why is Zig so cool?

#250

Post by 59nadir »

gethly wrote: post #224

Why are people so obsessed with Zig when Odin has been stable, though not yet with official spec, for such a long time and used in real production for years? Is it just syntax preference or does Zig provide something amazing that I am missing? Not that I use any of them, I am not interested in manual memory management and i stick to Go. But I'm curious.

Zig has a lot of manpower behind it in comparison to Odin and this is one of the most important things for people, they see a proverbial crowd and that builds a lot more interest.

With that said, here are a couple of things you have in Zig that you don't get in Odin:

- Cross-compilation & cross-linking (more or less works): Odin doesn't do cross-linking.

- Comptime; you can actually use it to effectively get Functors from ML, which means passing in interfaces to modules and getting compile-time generated modules back (structs in this case)

- Error set inference; Zig can figure out the complete set of errors a code path can return and make sure you handle them, or bubble that exact set (plus your own errors) up. This comes with the caveat that Zig has no capability to attach actual data to the errors, so you have to side-channel that info if you have it. Odin doesn't do error inference apart from the type checking side of it, but does allow using tagged unions as errors, which is great. They still interact exactly as they ought to with the zero-value-as-no-error machinery.

I didn't use comptime much when I used Zig, and I like tagged unions as errors much more than I value being able to cross-link, so I decided that Odin was better for me. Defaulting to zero-values and the zero-value being blessed in terms of language features didn't feel right to me before I started using it but now I can't really imagine going back to not assuming the zero-value being there.

Post reply on HN