[flohofwoe]

> I'm confused when people preach Zig and then safety in the same sentence.

Zig enforces correctness much more than C or C++ does (e.g. no implicit 'lossy' conversions, much stricter and enforced error handling, no implicit null, etc.), so it's completely fine to say that Zig is much safer than C or C++.

The main difference between Zig and Rust is the borrow checker, but a lot of memory corruption issues in C and C++ are "second order effects" of sloppy code which would be caught in Zig either at compile or runtime.

[pjmlp]

Except the little detail about sloppy use after free.

[flohofwoe]

Agreed but doing this at compile time would require some sort of pointer lifetime tracking in the compiler. Don't know how much of this is feasable without going "full borrow checker", but static analyzers for C do a similar thing, by far not as watertight as Rust of course.

The General Purpose Allocator can optionally catch use-after-free by not recycling virtual memory addresses, not very efficient for small high-frequency allocations of course, but then Zig isn't an OOP language either (where it would be common to create and destroy massive amounts of tiny objects).

[pjmlp]

> ...but static analyzers for C do a similar thing..

Exactly, which begs the question why bother with Zig at all.

[flohofwoe]

Zig is a much more ergonomic language, toolchain and build system. And since Zig is also a C/C++/ObjC toolchain, it's not about "Zig or C/C++", but about "Zig and C/C++" (at least from my PoV).

[pjmlp]

From my point of view it isn't enough to warrant adoption over existing alternatives.

Maybe someone proves me wrong with some killer application that makes Zig unavoidable for the rest of us.