My definition of safety is simply how many memory/UB bugs escape to production. This is quantifiable. Looking at open-source Zig projects, even highly competent programmers seem to be struggling. I’d love to dig deeper into what’s causing all these panics: how much comes from Zig’s great interop story, how much from common language footguns, and how much from its non-global-allocator-passing philosophy?
back
1 comments
If you have the data set of known bugs, going through them should give you the cause.
I do expect a strong correlation of basic coverage for simple UB things and input set/formulae coverage for the harder to hit ones, specifically as the code scales.
For formal proofs the effort scales quadratically, does Rust code also become quadratically slower with some constant factor? I'd assume runtime-checks could provide statistical safety and each component may need statistics tweaking unless being small enough/verified/edge cases enumerable with reasonable certainty etc. Are you aware of any known statistics or work besides the 0,x bugs per 1000 lines of code taking into account classes of bugs? Or what is your take on this?
I haven’t gone so far as to create a dataset, but you can use GitHub search to quickly peruse the top open source Zig repositories: https://github.com/search?q=+language%3AZig+stars%3A%3E1000&....
All of them, with the notable exception of tigerbeetle, a financial transactions database, have issue trackers which are littered with users reporting segfaults. I don’t really know if it’s more common than in popular Rust repositories, but this is my highly anecdotal, qualitative investigation.
What worries me is that when you dig into specific issues for root causes, there seem to be a lot of different root causes and not a lot of obvious fixes. And segfaults are just the tip of the iceberg, the most obvious memory errors. I don’t think people are reporting heap corruption in the same way, if ever.