I’ve seen companies losing their by far biggest customer because they refuse to hire real engineers instead of juniors to fix their software. The customer tried YEARS of complaining before.

Another customer: different suppliers use different barcode patterns for deliveries, some including nasty stuff like NULL as separators (but only sometimes, can be space, tab, whatever) or non-unique IDs. They rather spent the effort to fix everything else with workarounds than change the contract and demand proper barcodes/delivery data.

In Zig you need to call everything explicitly, meaning in the function you need to call what you want to be executed, no other code will run. The decision if you want some cleanup logic is made at the point of usage, not by the type itself.

That is the point of it, you look at a function and directly see what happens right there, not in other files/packages.

It is clear when it is called, but you have to check in code you are not currently seeing as any type could implement it. May seem like a minor thing, but is not explicit at the point of usage. In Zig only code you call explicitly runs, meaning if there is no defer nothing happens at the end of the scope.

Custom allocators are very nice. We are very much in manual memory management + optimization territory here. Having things like arena allocators makes a lot of difference in specific use-cases when you want/need every bit of performance. Also nice being able to switch the allocator for tests that is able to report leaks for example.

Yes, hidden control flow I mean something like exceptions, RAII or Rust's Dispose. So more a comparison to other languages than C.

The explanation I would refer to the talks "Don't forget to flush" or "Zig Roadmap 2026" from Andrew Kelley. Also the blog post "Zig's New Async I/O". I think it has something to do with being able to infer the required size of the stack, but already forgot the details.

https://kristoff.it/blog/zig-new-async-io/ https://youtu.be/f30PceqQWko?si=g2nLTE4ubWD14Zvn https://youtu.be/x3hOiOcbgeA?si=SUntYOYNOaxCRagc&t=3653

As to compared to Rust. The fast compile times are nice. Having a small language that you actually can understand helps to be productive. Not being restricted by the borrow checker makes it easier to implement some low-level things. Just being able to import most C code without wrapper makes the smaller ecosystem a much smaller problem. Rust is nice and certainly a good pick for many cases, but personally I often feel overwhelmed by the complexity and tons of tons of types for everything.

But it’s not only the language itself, it is also the tooling around it. Single unit of compilation has some nice properties, allowing to support colorless async. Fast compile times. Being able to use existing C code easily and having optimization across language boundaries. Cross compilation out of the box. Generally caring for performance in all aspects.

So for me it is a better C, low-level but still approachable and not having so much cruft.

Some others here asked how would we decide what is the same law. That’s pretty easy: same as with many other not so clear things, if some sues a judge/jury hears both sides and makes a decision.