The mentality around lifetimes is different in Zig if you are using it for the correct types of problems.

For example, a command line utility. In a CLI tool you typically don't free memory. You just allocate and exit and let the OS clean up memory.

Historically compilers were all like this, they didn't free memory, they just compiled a single file and then exited! This ended up being a problem when compilers moved more into a service model (constant compilation in the background, needing to do whole program optimization, loading into memory and being called on demand to compile snippets, etc), but for certain problem classes, not worrying about memory safety is just fine.

Zig makes it easy to create an allocator, use it, then just free up all the memory in that region.

Right tool for the job and all that.

I've been having an absolutely great time with Rust's bumpalo crate, which works very similarly. The lifetime protection still works great, and it's actually a lot more permissive than normal Rust, since it's the same lifetime everywhere.

The sad exception is obviously that Rust's std collections are not built on top of it, and neither is almost anything else.

But nevertheless, I think this means it's not a Zig vs Rust thing, it's a Zig stdlib vs Rust stdlib thing, and Rust's stdlib can be replaced via #[no_std]. In the far future, it's likely someone will make a Zig-like stdlib for Rust too, with a &dyn Allocator inside collections.

I'm not convinced that you can't borrow check in zig... (disclaimer, i'm working on compile time memory safety for zig)