[anp]

I find a lot of these points persuasive (and I’m a big Rust fan so I haven’t spent much time with Zig myself because of the memory safety point), but I’m a little skeptical about the bug report analysis. I could buy the argument that Zig is more likely to lead to crashy code, but the numbers presented don’t account for the possibility that the relative proportions of bug “flavors” might shift as a project matures. I’d be more persuaded on the reliability point if it were comparing the “crash density” of bug reports at comparable points in those project’s lifetimes.

For example, it would be interesting to compare how many Rust bugs mentioned crashes back when there were only 13k bugs reported, and the same for the JS VM comparison. Don’t get me wrong, as a Rust zealot I have my biases and still expect a memory safe implementation to be less crashy, but I’d be much happier concluding that based on stronger data and analysis.

[kennykartman]

I had the same thought. But one thing was actually very useful to compare "bug densities": deno vs bun. They have comparable codebase sizes as well as comparable ages (7y vs 4y). I'd like to see the same stats for tigerbeetle, which is very carefully designed: if segfaults were relatively high on that as too, well...

[cb22]

> I'd like to see the same stats for tigerbeetle

Actual SIGSEGVs are pretty rare, even during development. There was a pretty interesting one that affected our fuzzing infra a little bit ago: https://ziggit.dev/t/stack-probe-puzzle/10291

Almost all of the time we hit either asserts or panics or other things which trigger core dumps intentionally!

[williamstein]

bun has 10x the issues matching "segfault" as deno

- deno 44: https://github.com/denoland/deno/issues?q=is%3Aissue%20state...

- bun 464: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...

[bsder]

> Don’t get me wrong, as a Rust zealot I have my biases and still expect a memory safe implementation to be less crashy

That is a bias. You want all your "memory safety" to be guaranteed at compile time. Zig is willing to move some of that "memory safety" to run time.

Those choices involve tradeoffs. Runtime checks make Zig programs more "crashy", but the language is much smaller, the compiler is vastly faster, "debug" code isn't glacially slow, and programs can be compiled even if they might have an error.

My personal take is that if I need more abstraction than Zig, I need something with managed memory--not Rust or C++. But, that is also a bias.

[anp]

I understand that I have a bias, which is why I was disclosing it. I think it strengthens my question since naively I'd expect a self-professed zealot to buy into the narrative in the blog post without questioning the data.

[Defletter]

> My personal take is that if I need more abstraction than Zig, I need something with managed memory--not Rust or C++

You may potentially like D. Its tooling leaves much to be desired but the language itself is pretty interesting.