Live data from Hacker News

Why is Zig so cool?

nilostolte.github.io

81–90 of 527 posts

Re: Why is Zig so cool?

#81
post #8

A neat little thing I like about Zig is one of the options for installing it is via PyPI like this: https://pypi.org/project/ziglang/ pip install ziglang Which means you don't even have to install it separately to try it out via uvx. If you have uv installed already try this: cd /tmp echo '#include int main() { printf("Hello, World!"); return 0; }' > hello.c uvx --from ziglang python-zig cc /tmp/hello.c ./a.out

For this sort of stuff I find micromamba / pixi a better way of managing packages, as oppposed to the pip / uv family of tools

Pixi, Conan, or Nix— all better choices than abusing the Python ecosystem to ship arbitrary executables.

Re: Why is Zig so cool?

#82

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 comes to error handling. The conditional late binding of error context lets you choose when and where to do it when it makes sense and is likely to be safe.

A fundamental caveat of systems languages is that expediency takes a back seat to precision, performance, and determinism. That's the nature of the thing.

Re: Why is Zig so cool?

#83

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…

This seems kinda contrived. In practice that "ERROR DATA" tends not to exist. Unexpected errors almost never originate within the code in question. In basically all cases that "ERROR DATA" is just recapitulating the result of a system call, and the OS doesn't have any data to pass.

And even if it did, interpreting the error generally doesn't every work with a microscope over attached data. You got an error from a write. What does the data contain? The file descriptor? Not great, since you really want to know the path to the file. But even then, it turns out it doesn't really matter because what really happened was the storage filled up due to a misbehaving process somewhere else.

"Error data" is one of those conceits that sounds like a good idea but in practice is mostly just busy work. Architect your systems to fail gracefully, don't fool yourself into pretending you can "handle" errors in clever ways.

Re: Why is Zig so cool?

#84
I like D better. And had some of the "cool" features of Zig from quite some time, such as scope(exit) which is clearer.

I don't find Zig nearly as readable as my D code, but alas, I don't do systems programming.

Re: Why is Zig so cool?

#85

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…

This is annoying. It’s because errors were designed to be a bitset and not have pointers. I would also prefer that they were a `union(enum)`.

We are free to do that as a return type like `Result(T)` and just forgo using `try`, but yeah, I wish this was in there.

Re: Why is Zig so cool?

#86

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…

People are working on this. std.zon is generally considered to be a good example of how to handle errors and diagnostics, though it's an area of active exploration. The plan is to eventually collect all the good patterns people have come up with and (1) publish them in a collection, and (2) update std to actually use them.

Re: Why is Zig so cool?

#87
post #83

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…

This seems kinda contrived. In practice that "ERROR DATA" tends not to exist. Unexpected errors almost never originate within the code in question. In basically all cases that "ERROR DATA" is just recapitulating the result of a system call, and the OS doesn't have any data to pass. And even if it did, interpreting the error generally doesn't every work with a microscope over attached data. You got an error from a wri…

Seralizing error data to text and then dumping that in a log can be pretty useful.

Re: Why is Zig so cool?

#88
post #83

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…

This seems kinda contrived. In practice that "ERROR DATA" tends not to exist. Unexpected errors almost never originate within the code in question. In basically all cases that "ERROR DATA" is just recapitulating the result of a system call, and the OS doesn't have any data to pass. And even if it did, interpreting the error generally doesn't every work with a microscope over attached data. You got an error from a wri…

I think you've skipped over all the cases where knowing the filename is actually helpful? It's true that sometimes it isn't.

Also, a line number is often helpful, which is why compilers include it. Some JSON parsers omit that, which is annoying.

Re: Why is Zig so cool?

#89
post #39

Earlier quoted context omitted.

> Isn't cross compilation very, very ordinary? Working cross compilation out of the box any-to-any still isn't.

Yes, very rare and there is a strong cartel of companies ensuring it doesn't happen in more mainstream langs through multiple avenues to protect their interests! From helicoptering folks onto steering committee and indoctrination of young CS majors.

This comment deserves a [citation needed] visible from geosynchronous orbit.

Re: Why is Zig so cool?

#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.

Post reply on HN