Zig at least claims some level of memory safety in their marketing. How real that is I don't know.

About as real as claiming that C/C++ is memory safe because of sanitizers IMHO.

I mean, Zig does have non-null pointers. It prevents some UB. Just not all.

Which you can achieve in C and C++ with static analysis rules, breaking compilation if pointers aren't checked for nullptr/NULL before use.

Zig would have been a nice proposition in the 20th century, alongside languages like Modula-2 and Object Pascal.

I'm unaware of any such marketing.

Zig does claim that it

> ... has a debug allocator that maintains memory safety in the face of use-after-free and double-free

which is probably true (in that it's not possible to violate memory safety on the debug allocator, although it's still a strong claim). But beyond that there isn't really any current marketing for Zig claiming safety, beyond a heading in an overview of "Performance and Safety: Choose Two".

Runtime checks can only validate code paths taken, though. Also, C sanitizers are quite good as well nowadays.

That's a library feature (not intended for release builds), not a language feature.

It is intended for release builds. The ReleaseSafe target will keep the checks. ReleaseFast and ReleaseSmall will remove the checks, but those aren't the recommended release modes for general software. Only for when performance or size are critical.

DebugAllocator essentially becomes a no-op wrapper when you use those targets.

I have heard different arguments, such as https://zackoverflow.dev/writing/unsafe-rust-vs-zig/ .