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.
> it just defines that safety in a different way than Rust
Memory safety is already well-defined, though. It means that you can’t write code that mishandles memory in a dangerous way. In Rust, code outside of unsafe blocks is guaranteed to have this property. As far as I know, no such feature exists in Zig. So Zig is starting from a point where it can’t guarantee the safety of any nontrivial program, right?
Can rust _gaurantee_ memory safety? A lot of the core features are built on-top of unsafe {} blocks after all. Zig has it's own memory safe features which will catch a lot of memory safe bugs compared to Vanilla C.
asan/valgrind/etc. will also pick up a lot of memory bugs for C and C++.
Outside of maybe formal proofs in languages that only exist in research labs there isn't anything that is _provably safe_. This discussion and worship of languages which advertsie themselves as "memory safe" seems a bit zealous and often not useful. I do prefer rust over C++, mainly due to better defaults (immutable variables) and stripping out the object orientated paradigm which just gets abused after 25 years of "enterprise design patterns".
After a few years, rust is going to have just as much dodgy software as much established languages. You can see it now with people trying to write in rust as pythonic as possible and littering the place with .unwrap(). That's not a sign of quality/stable software, even if it is written in a 'memory safe' language.
The formal proof doesn’t exist yet but the language was designed from the ground up with memory safety as a key principle.
I should note, Rust is not the only safe language. Python is safe, as are most modern languages with garbage collection. Most code can afford a garbage collector and should probably use one. My day job is real-time network + web services with Elixir/Erlang, and it works great. Rust gets brought up in contrast to Zig because it brings the benefits of those higher-level languages down to the metal.
I think the horizontal vs vertical memory safety argument needs to be better marketed. Because right now Memory safety PL is quite literally trademarked by Rust in any discussions.
now please translate it into non-marketing words, please.
He says Rust is on the top safe (vertical), but not at the bottom, because the bottom isn't fully proven.
He also says Zig is horizontally safe -> there is unsafe code on any layer, but also safe code.
Also, it doesn't seem like there is something like "unsafe" for Zig. How can you say anything is safe then?
So Zig has one feature that makes it harder (impossible?) to write broken code than with Rust in UNSAFE code.
How does this bring anything to the table besides eloquently dismiss Rusts safety guarantees? E.g. allowing to state libraries to only have safe code in them>
Afaik Rust let's you fully use the HW as well (and as much as possible within safe code).
The safety guarantees don't come for free. There are tradeoffs. That should be clear from the fact that Rust as a language is still changing, i.e. relaxing ownership rules and adding new mechanisms to the type system. If there were no problems, then there would be no language changes necessary.
Examples of people writing Rust code and hitting problems of expressiveness and performance:
> [...] 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.