I don’t think it’s about being a spectrum. It’s about having different paths to the same goal. GC is one well-proven path. Rust / Borrow checker is another path, with other benefits and limitations. Zig is well on its way to a third path with potentially the same level of safety and different benefits and limitations.

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.

> Zig is well on its way to a third path with potentially the same level of safety

No. Zig says it wants to get to where Fil-C is, for a specific release mode that most people won't use, and it doesn't have even an outline of how that would work.

That's nowhere close to the "same level of safety" as (safe) Rust or Java has. We're going to see all the same bugs and all the same excuses as before.