There was an article about Zig on the front page just a few hours ago that attracted many "Why do I need memory safety?" comments. The fact that new languages like Zig aren't taking memory safety as a foundational design goal should be evidence enough that many people are still skeptical about its value
Zig's approach to memory safety is an open question. I don't like it (obviously, a very subjective statement), but as more software is written in it, we'll get empirical data about whether Zig's bet pays off. It very well might.
The post in question had early empirical data comparing bug reports from Node, Bun and Deno. It wasn't the main focus of the article, and I would love to see a deeper dive, but it showed that Bun had almost 8x the amount of "crash" or "segfault" bug reports on Github as Deno, despite having almost the same amount of total issues created. (4% of bug reports for Deno are crashes, 26% of bug reports for Bun are crashes).
This matches my experience with the runtimes in question—I tried Bun out for a very small project and ran into 3 distinct crashes, often in very simple parts of the code like command line processing. Obviously not every crash / null-pointer dereference is a memory safety issue, but I think most people would agree that Zig does not seem to make bug-free software easier to write.
Indeed segfaults aren't necessarily a symptom of memory unsafety. But also, Go is not memory safe due to the possibility of races in multithreaded code.
