←back to thread

Zig is hard but worth it

(ratfactor.com)
401 points signa11 | 8 comments | | HN request time: 0.246s | source | bottom
1. 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 #
2. Symmetry ◴[] No.36153812[source]
Assuming that bytes are 8 bits long or that negative numbers are represented with two's complement is a lot less dangerous these days than it was when C came along.
3. pklausler ◴[] No.36153952[source]
Ironically, C is now way more portable than modern Fortran is. The Venn diagram of feature portability across the 6 or 7 actively-maintained Fortran compilers is very messy.
4. 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 #
5. 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).
6. tialaramex ◴[] No.36157133[source]
This makes no sense because C89 is defined for execution on a abstract machine, something which doesn't exist and thus has no hardware.

Such beliefs are however compatible with the inveterate C programmer excuse that their nonsense programs should be correct if only the standards committee, compiler vendors, OS designers, and everybody else in the known universe were not conspiring to defeat their clear intent.

replies(1): >>36157289 #
7. kps ◴[] No.36157289{3}[source]
From the C89 Rationale, “The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine’s hardware does it rather than by a general abstract rule. An example of this willingness to live with what the machine does can be seen in the rules that govern the widening of char objects for use in expressions: whether the values of char objects widen to signed or unsigned quantities typically depends on which byte operation is more efficient on the target machine.”
replies(1): >>36157960 #
8. tialaramex ◴[] No.36157960{4}[source]
> many operations are defined

My emphasis. Undefined Behaviour is not an example of operations being defined.