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

121–130 of 527 posts

Re: Why is Zig so cool?

#121

Post by sho_hn »

jandrewrogers wrote: post #117
sho_hn wrote: post #103

Earlier quoted context omitted.

Interesting, but really in need of some examples.

I would highlight `std::launder` as an example. It was added in C++17. Famously, most people have no idea what it is used for or why it exists. For low-level systems it was a godsend because there wasn’t an official way to express the intent, though compilers left backdoors open because some things require it. It generates no code, it is a compiler barrier related to constant folding and lifetime analysis that is par…

This is a good example because I'm familiar with it (I'm a C++ programmer; I haven't had occasion to use `launder`, but I read about it back then).

But what's the Zig equivalent?

Re: Why is Zig so cool?

#122

Post by jibal »

RagnarD wrote: post #90

"This associated with the ability to cross-compile code to be run in another architecture, different than the machine where it is was originally compiled, is already something quite different and unique." Perhaps I'm missing something but this is utterly routine. It even has the name used here: Cross-compiling.

If you install Zig, you can now generate executables for virtually any target with just a CLI argument specifying the target, regardless of what machine you installed it on. Nothing else does that--cross compilation generally requires compiling the compiler to target a different architecture.

Re: Why is Zig so cool?

#123

Post by jibal »

meisel wrote: post #25

For a language that’s so low level and performance focused, I’m surprised that it has those extra io and allocator arguments to functions. Isn’t that creating code bloat and runtime overhead?

Every class method in other languages receives a hidden argument. Odin passes a hidden context argument that contains the allocator. The alternative is global variables--which you can also use in Zig if you're so inclined. The extra arguments aren't something the Zig language imposes, it's a convention.

Re: Why is Zig so cool?

#124

Post by BoorishBears »

ksenzee wrote: post #114
BoorishBears wrote: post #107

Earlier quoted context omitted.

[flagged]

Sometimes if a joke doesn't land, it's because the joke wasn't funny. (Also, yes, a lot of folks here are autistic, maybe cool it with the veiled insults.)

Sure sometimes... other times you get deadpan replies unironically demanding citations and proof of claims.

There's nothing veiled or an insult: what I mentioned is a real factor in why people would read that statement and jump to demanding proof.

-

If I told a room full of plumbers that Sharkbites are actually sponsored by big Water trying to encourage water wastage, it definitely might not land... but none of them are going to demand a citation!

Re: Why is Zig so cool?

#125

Post by FragenAntworten »

fastball wrote: post #19
hamandcheese wrote: post #3

Zig being able to (cross)compile C and C++ feels very similar to how UV functions as a drop in replacement for pip/pip-tools. Seems like a fantastic way to gain traction in already established projects.

Strangler fig

This is referring to the Strangler Fig design pattern, which is relevant: https://learn.microsoft.com/en-us/azure/architecture/pattern...

Re: Why is Zig so cool?

#126

Post by jibal »

garbagepatch wrote: post #50
meisel wrote: post #25

For a language that’s so low level and performance focused, I’m surprised that it has those extra io and allocator arguments to functions. Isn’t that creating code bloat and runtime overhead?

Regarding runtime overhead, I'd assume you would still need an io implementation, it is just showing it to you explicitly instead of it being hidden behind the std lib. For simple projects where you don't want to pass it around in function parameters, you can create a global object with one implementation and use it from everywhere.

You still have to pass arguments to library functions that need to allocate or do I/O ... but the alternative is worse. This is really a bogus issue ... no one is crying over having to pass a `this` pointer to every single call of a method in other languages. Context pointers are a requirement in any sizeable or multi-threaded program, and Zig gives the user full control over what the context object looks like.

Re: Why is Zig so cool?

#127

Post by qouteall »

jandrewrogers wrote: post #82
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…

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.

Re: Why is Zig so cool?

#128

Post by jibal »

rvrb wrote: post #28
meisel wrote: post #25

For a language that’s so low level and performance focused, I’m surprised that it has those extra io and allocator arguments to functions. Isn’t that creating code bloat and runtime overhead?

the answer I've seen when it has been brought up before is that (for allocators) there is not a practical impact on performance -- allocating takes way more time than the virtual dispatch does, so it ends up being negligible. for code bloat, I'm not sure what you mean exactly; the allocator interface is implemented via a VTable, and the impact on binary size is pretty minimal. you're also not really creating more tha…

He's talking about passing the pointers to the allocators and Io objects as parameters throughout the program, not how allocator vtables for calling the allocator's virtual functions are implemented. But context pointers are a requirement in any program. Consider that a context pointer (`this`) is passed to every single method call ... it's no more "code bloat" than having to save and restore registers on every call.

Re: Why is Zig so cool?

#129

Post by librasteve »

jandrewrogers wrote: post #82
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…

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…

For quite a long time, I have been wondering why I like to code in Raku so much … in a round about way you set me thinking. Perhaps it’s because, in Raku, precision, performance and determinism take a back seat to expediency. (Sorry for the tangent).

Re: Why is Zig so cool?

#130

Post by qouteall »

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…

I agree that building a special diagnostic system is better than just using language's builtin error system. However that takes efforts.

Library developers tend to choose the path of least resistance, which is to not pass diagnostic information.

The most convenient diagonistic system is the good old logging. Logging is easy.

Maybe logging will be the de facto solution of passing error data in Zig ecosystem, due to psychological reasons.

Post reply on HN