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.

The never-ending discussion of LLM-generated code in binary terms is tiring. It’s either all completely useless slop (which is the author’s stance), or it’s infallible and should be maximized at all costs. Yes there is slop, but there is also good or even great code produced by those making use of LLMs. I understand why a maintainer of a large project like Zig may outright reject LLMs for sheer practicality matters, just to stay on top of the wave of slop generated contributions. But it makes very little sense when a consumer of code, such as the author, takes a black and white stance on if LLM generated code is accepted by the language. If anything, it feels like an intellectual crutch. No need to understand technical nuances when you can fallback on dogmatic zeal.