I would compare the recent Rust Android post [1], where they have a 5000x lower memory vulnerability rate compared to traditional C/C++ with the number of segfaults found in Bun. [2]

In my opinion Zig does not move the needle on real safety when the codebase becomes sufficiently complex.

[1]: https://security.googleblog.com/2025/11/rust-in-android-move...

[2]: https://github.com/oven-sh/bun/issues?q=segfault%20OR%20segm...

▲ dns_snek 2 hours ago | parent [-]

Why are we comparing a number of exploitable vulnerabilities to the number of segfault reports? Where does the "5000x" figure come from?

▲ ViewTrick1002 an hour ago | parent [-]

The number is memory vulnerabilities. Not if they are exploitable. The numbers comes from this part of the article:

    This near-miss inevitably raises the question: "If Rust can have memory safety vulnerabilities, then what’s the point?"

    The point is that the density is drastically lower. So much lower that it represents a major shift in security posture. Based on our near-miss, we can make a conservative estimate. With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC).

    Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction.

https://security.googleblog.com/2025/11/rust-in-android-move...