I think Andrew would contend that it is memory safe, it just defines that safety in a different way than Rust:
> [...] So, the way I would describe it is that Rust has a kind of like vertical memory safety approach where on the top, it’s safe. And then, on the bottom, you hit the unsafe block, and it’s not safe, right? [...] Zig is more of I would say horizontal safety approach. So, there’s no unsafe blocks where it’s all contained in, but each feature of the language models safety in a different way. So, as an example, the pointer type in Zig actually can represent alignment. In Rust, if you want to mess with pointer alignment, you have to use an unsafe block and you’ve turned off safety for alignment. In Zig, you have pointer alignment in the type. So, it’s actually completely safe, and in Rust it’s not.
And of course the reason it doesn't use anything like a borrow checker:
> [...] Zig also wants to be optimal and optimal means you want to fully use the hardware that you have. So, my hardware lets me use virtual memory and it lets me use intrusive data structures. And it lets me write code in a certain way that’s the most efficient way to use all the CPU and all the memory. So, if my language doesn’t let me use all my hardware features, it’s not optimal.
I can't help but agree. We should strive to allow optimal code to work, and we should also do our best to prevent the programmer from doing unsafe things unless they are explicit about what they're doing. Are programmers sometimes going to do the wrong thing anyway? Yes, of course. The same way that someone can get frustrated and wrap their code in unsafe, they can use @ptrToInt without thinking it through.
> [...] So, the way I would describe it is that Rust has a kind of like vertical memory safety approach where on the top, it’s safe. And then, on the bottom, you hit the unsafe block, and it’s not safe, right? [...] Zig is more of I would say horizontal safety approach. So, there’s no unsafe blocks where it’s all contained in, but each feature of the language models safety in a different way. So, as an example, the pointer type in Zig actually can represent alignment. In Rust, if you want to mess with pointer alignment, you have to use an unsafe block and you’ve turned off safety for alignment. In Zig, you have pointer alignment in the type. So, it’s actually completely safe, and in Rust it’s not.
And of course the reason it doesn't use anything like a borrow checker:
> [...] Zig also wants to be optimal and optimal means you want to fully use the hardware that you have. So, my hardware lets me use virtual memory and it lets me use intrusive data structures. And it lets me write code in a certain way that’s the most efficient way to use all the CPU and all the memory. So, if my language doesn’t let me use all my hardware features, it’s not optimal.
I can't help but agree. We should strive to allow optimal code to work, and we should also do our best to prevent the programmer from doing unsafe things unless they are explicit about what they're doing. Are programmers sometimes going to do the wrong thing anyway? Yes, of course. The same way that someone can get frustrated and wrap their code in unsafe, they can use @ptrToInt without thinking it through.