Why Zig over C for Systems Programming

Re:Why Zig over C for Systems Programming by tialaramex on Friday November 13, 2026 @03:13PM (#50489004)

> The resolution of `foo` in `foo(x)` should not depend on the type of `x`

This depends on how you're squinting at this word "resolution".

Remember on a modern CPU an XOR R1 R1 does not result in an ALU operation, the decoder understands this idiom and just renames a zero'd register as R1, whereas of course it can't do that for say XOR R2 R3 because that's an actual XOR operation. So if "resolution" means "exactly what happens on the CPU" apparently there is no such facility provided even in assembler.

So apparently we mean only that it should have, in some sense, the same effect. I think the fact Rust is OK with

  assert!("Goose".contains('o'))
  assert!("Goose".contains("Goo"))
  assert!("Goose".contains(&['a', 'e', 'i', 'o', 'u']))

.. meets this criterion, whereas presumably you do not agree.

[ Parent | on HN ]

Re:Why Zig over C for Systems Programming by pron on Friday November 13, 2026 @03:24PM (#50489133)

It's not about okay or not okay. Zig is designed to prevent any user code from being implicitly called, or for the resolution of user code to be done implicitly. It's not about what the CPU does internally, but whether you're able to tell, from reading the code of a single subroutine, which operations could be done, whether stack frames can be created etc.. This has pros and cons, and for some people the pros outweigh the cons and for others, the other way around, and that's why different programming languages need to prioritise different things when they target different users.

[ Parent | on HN ]