←back to thread

Zig is hard but worth it

(ratfactor.com)
401 points signa11 | 1 comments | | HN request time: 0.207s | source
Show context
parasense ◴[] No.36153766[source]
The main take away is:

> Something that makes Zig harder to learn up front, but easier in the long run is lack of undefined behavior.

Reminds me of the old discussions of Fortran Vs C, and specifically in the early times before C had a standard library. What we call "undefined behaviour" was just an idiom of the language where the "behaviour" was sometimes on purpose, but recognised might not be portable. And so the point here is the idea of undefined behaviour is tied to portability on some levels, and isn't just some purely academic idea about the compiler or abstract syntax trees.

So I'm concerned about the potential over-zealous prejudice against undefined behaviour, but I think we can all agree deterministic software is better than otherwise. The catch is that sometimes UB is deterministic, and yet dares to not be idiomatic.

replies(3): >>36153812 #>>36153952 #>>36154133 #
kps ◴[] No.36154133[source]
C89's ‘undefined behavior’ was a failed attempt to say “you get what the hardware gives you”.
replies(2): >>36154438 #>>36157133 #
1. jsmith45 ◴[] No.36154438[source]
Yeah. In hindsight for a fair bit of it, it could have been sensibly changed to implementation defined behavior, or to constrained unspecified behavior. (Constrained such that people know what the possibilities are, but the compiler need not document its choice, and might not make the same choice in all circumstances. The latter could allow for scenarios where letting an optimizer do the faster thing when detectable, and what the hardware natively does otherwise, for example. Obviously still a potential footgun, but less of one than full undefined behavior).