|
|
|
|
|
by lpghatguy
24 days ago
|
|
I find it frustrating when people talk about memory safety as “a spectrum.” Yes, there are safer patterns in unsafe languages, but at the end of the day, not having memory safety as a category of bug _period_ is such a nice baseline level to work from! If you hit a weird state in your program and it can _never_ be caused by memory corruption, you rule out a big bug space and no longer need to check the entire scope of your program. It’s similar to Rust’s unsafe blocks — it doesn’t really matter if they’re “more unsafe” than Zig because in Zig the scope of the unsafe is your entire program! Local reasoning is a huge part of what you buy into and I could never give that up if I didn’t have to. |
|
Zig will depend on having tests with good coverage, and you should probably use fuzzing. But if you care about safety and stability, why would you not write tests? Memory bugs are not the only class of safety and stability issues we should care about. So I don’t think we should be dismissive of an approach that takes a more holistic approach to those, while also providing really solid memory safety.
I am sure we will see solid static analysis tools for Zig which can weed out a lot of stuff before runtime as well. The developers of the language seem very interested in that approach but need to focus on other things first.