The reason I find this sort of comment annoying is that it implies that Rust actually reaches 100% safety, when it clearly doesn’t. Or alternatively implies that you can’t reach the same level of safety with Zig. Both those implications aren’t true.
The uninformend reader will read this as:
Yeah, with Zig you can get like 99% of the way to the safety that a Rust program will bring.
(only the second safe removed)
But the difference between those two sentences is still massive with Rust, so it seems disingenuous to hype up Rust saying the first thing while many naive readers will take it for the second thing.
So what is the difference?
Logic, Rust implementation, Rust soundness/type-system, Operating System and hardware bugs/exploits.
That second safe serves as a means to say that you have made sure that all those problems don’t actually result in any real problems that can be exploited, so when Rust is presented in a way where you easily can read it as if it took care of those problems, but you didn’t, that is where it becomes more like a advertisement trying to over sell their product, through cleverly technically correct language that still sells a false impression of what it actually is.
That it is sold that way makes me trust it less, they should just outright say we help you with many memory related safety issues, so that you can focus your critical thinking time on the remaining harder problems, instead of implying that general safety was solved.
I don’t like the way you framed it and I think that somebody who actually is interested in delivering that second safe (in safe program), also can implement a process using Zig that ensures the same or depending on what they do, potentially even better safety, than a Rust program (because that second safe is largely in the responsibility of the programmer, regardless of the language they use[1], but personally I would bet that if I used Zig to reach such a goal I would get there faster than if I tried to use Rust for it (partly because Rust would result in too much sword fighting time 
)))
The difference between Zig and Rust isn’t the potentially reachable safety, but how much responsibility you have to accept as the programmer to actually reach some specific level of safety, Zig requires that you accept more responsibility for what you produce, instead of trying to hide that responsibility by obscuring the problem and over selling ideas that aren’t actually delivered automatically/magically. Rust can help with some problems, it can even be the better tradeoff for certain problems/goals and certain workflows, but stop with the hype stuff and implying it had some absolute increase in the achievable quality.
I am willing to bet that a lot of the memory safety related savings in developer time are wasted by Rusts slow compile times, especially if the programmer using it has learned to not make so many memory related errors to begin with. Also if you have reason to care about those sort of errors you can still use a lot of other tooling in addition to Zig like code tracing, validation, etc., to close the gap between Zig and Rust in being able to handle memory safety and having an efficient workflow around that. Rust gives you one option that you can’t practically opt-out off (you get stuck with the negative effects of the tradeoff), Zig gives you many options that you have to opt in to, where opt in requires a higher time and effort investment (because you are bolting things onto Zig, or figuring out how to use them alongside Zig).
except if the language is a completely proven chain from start to finish and its proofs are actually proving the right thing (the proof itself isn’t faulty) and then it runs on hardware in a way that faults get error corrected (and don’t result in mission failure like coming up with the correct answer, after the patient already died from the heart attack, in a too slow peacemaker) ↩︎
if you present this as a blog post with links to prior discussions!
).