3 ms·

> it's just silly to draw a a particular sharp line between Rust and Zig because they perform exactly the same (in terms of sound guarantees; we're ignoring any

> it's just silly to draw a a particular sharp line between Rust and Zig because they perform exactly the same (in terms of sound guarantees; we're ignoring any softer effects) for most top weaknesses. There is a very clear sharp line between them in that Rust has no undefined behavior outside of an unsafe block. This matters because the effects of undefined behavior -- particularly memory-corrupting undefined behavior -- are unbounded. Security issues caused by logic bugs are limited to only having local effects on the program -- a SQL injection bug can lead to the wrong SQL query being executed, a path traversal bug can lead to the wrong path being accessed, and a shell escaping bug can lead to execution of the wrong shell command. These are severe problems that can lead to data exfiltration or remote code execution, but the relationship between bug and effect is straightforward: "I'm passing user input to a shell here; this could have catastrophic consequences so I'd better review this carefully." In contrast, undefined behavior can happen anywhere in your program, and it can do anything. That is a clear and measurable difference, and emperical evidence from the last 10 years clearly indicates both that it is nigh impossible to write large C/C++ applications without both spatial and temporal memory safety vulnerabilities, and that adopting Rust measurably decreases the incidence of such vulnerabilities. Zig is certainly an improvement over C on this front, but it is still a UB-heavy language, and that's where the sharp line is. It's hard to make emperical comparisons because Zig is so young, but the comparision between Deno and Bun in the article is a reasonably strong demonstration that Zig has not achieved a comparable level of memory safety to Rust. > Sure, but then you might as well also consider softer effects. For example, maybe a language that's easier to review because it's more explicit, or a language that's faster to compile and is easier to test wins. > And I agree that we should consider all these, but then we start seeing why correctness is such a complicated topic, and we could speculate just as easily that it is Zig that "clearly" wins. This doesn't really have anything to do with my point that the CVE list does not provide evidence to dismiss temporal memory safety as irrelevant; it's more of a general statement on writing correct software. But regardless, "Zig has nullability and bounds checks" and "Rust has an affine type system, statically-checked immutability and exclusivity, language-level resource management, and no undefined behavior" are not in the same league of program correctness. Rust wasn't designed after some ideal of memory safety at the expense of clarity and correctness: the lifetime and type system came from a goal of reducing logic bugs in complex concurrent programs, and the fact that it is powerful enough to achieve memory safety without garbage collection was a happy accident. The emperical results that Rust programs have fewer memory-safety vulnerabilities demonstrate that Rust's static approach to software correctness is successful, and not just for the specific problem of memory safety, because Rust's tooling for achieving program correctness is generalizable to arbitrary application invariants. This lines up with my own experience; software I write using Rust is far easier to get right, more reliable, and easier to successfully maintain and refactor than anything else I've done. Certainly Zig has its strong points as well -- explicitness can reduce complexity and compile times, but it also has downsides of pushing complexity into application code (thus making it harder to review and introducing more opportunities to create mistakes). A proper comparison of the two approaches is worthwhile, but just as "Rust is more memory safe" is an overly reductive generalization of the langauges' approach to software correctness, "there's a rather small difference between Rust and Zig" simply isn't true.

pron 11mo ago
> There is a very clear sharp line between them in that Rust has no undefined behavior outside of an unsafe block. Yes, but that's an intrinsic language feature whose value needs to be justified somehow. If you justify it by saying it prevents dangerous vulnerabilities, we're back to my point. > This matters because the effects of undefined behavior -- particularly memory-corrupting undefined behavior -- are unbounded... While I appreciate this explanation (and I've seen it many times), I hope you understand that it's more speculative and subjective than an empirical finding. At the end of the day, to measure the danger of a problem, we need to see what the actual vulnerabilities/exploits are and how common they are. Clearly, not all undefined behaviours are equally exploitable. That's why we see differences in weakness severity among different kinds of UB. > emperical evidence from the last 10 years clearly indicates both that it is nigh impossible to write large C/C++ applications without both spatial and temporal memory safety vulnerabilities Right, and that same empirical evidence shows that spatial violations are the more dangerous ones, and that's exactly why Zig prevents them. > but the comparision between Deno and Bun in the article What article? It seems that Bun has had one CVE. If you're talking about undefined behaviour you're, again, making an unjustified extrapolation from it to security. Some undefined behaviour leads to easily exploitable vulnerabilities, some does not. It's true that in the presence of UB, the compiler could hypothetically do anything, but to get a dangerous vulnerability it has to actually do something that's exploitable, and when we look at vulnerabilities caused by UB, we see that some kinds are more dangerous than others because of that. BTW, this touches on something that is sometimes misunderstood about UB. UB is defined with respect to a language specification, i.e. in the presence of UB, the language specification does not assign a program a meaning, but the compiler certainly does, because machine code has no UB. The program with the UB needs to compile to an exploitable binary for a vulnerability to exist. > and that's where the sharp line is I agree it's a sharp intrinsic line, just as saying that Zig avoids macros is a sharp line, but the impact of that line is anything but sharp. To draw the practical conclusion from it you don't follow the findings, but ignore them! > This doesn't really have anything to do with my point that the CVE list does not provide evidence to dismiss temporal memory safety as irrelevant I wasn't dismissing it as irrelevant. I was saying that if Rust's value is in eliminating dangerous vulnerabilities, then Zig has that value, too, and the difference between them isn't large on that particular front. > are not in the same league of program correctness Software correctness is something I've been dealing with and writing about for many years, especially formal verification (https://pron.github.io https://pron.github.io), and I can tell you that you're downright wrong on that. That "more sound guarantees is always the most effective form of improving correctness" is something we know (at least since the nineties) not to be generally true, which is also why the field is looking more and more into unsound methods. For example, Rust and Zig are more likely to effectively write correct programs than ATS, even though ATS is "in a different league" from both of them when it comes to sound guarantees. We know that sound guarantees can help, but that their cost matters a lot. We also know that reviews and tests and dynamic verification are very effective, sometimes more than sound guarantees. Rust proponents are free to speculate that, ultimately, Rust's approach leads to more correctness than Zig, and they can base that belief on some findings, and Zig proponents can do exactly the same in the opposite direction, also based on other findings, but both are speculations. People are free to choose which they are more inclined to believe, but the question isn't settled. > This lines up with my own experience; software I write using Rust is far easier to get right, more reliable, and easier to successfully maintain and refactor than anything else I've done. I'm not doubting that that's your experience. I'm saying we have no evidence that it's universal, likely to be universal etc. (and I know of some opposite experiences with Rust). Sometimes certain languages just click with certain people, but we can't extrapolate without more observation. > "there's a rather small difference between Rust and Zig" simply isn't true. The correctness difference between the two is unknown. It could be small or large and in either direction. The intrinsic differences are, of course, known, but don't really help reach an objective preference. My point was only that if we judge Rust by the vulnerabilities it soundly eliminates, then Zig is not far on that particular metric, and it's certainly much closer to Rust than to C.

pron 11mo ago

> There is a very clear sharp line between them in that Rust has no undefined behavior outside of an unsafe block. Yes, but that's an intrinsic language feature whose value needs to be justified somehow. If you justify it by saying it prevents dangerous vulnerabilities, we're back to my point. > This matters because the effects of undefined behavior -- particularly memory-corrupting undefined behavior -- are unbounded... While I appreciate this explanation (and I've seen it many times), I hope you understand that it's more speculative and subjective than an empirical finding. At the end of the day, to measure the danger of a problem, we need to see what the actual vulnerabilities/exploits are and how common they are. Clearly, not all undefined behaviours are equally exploitable. That's why we see differences in weakness severity among different kinds of UB. > emperical evidence from the last 10 years clearly indicates both that it is nigh impossible to write large C/C++ applications without both spatial and temporal memory safety vulnerabilities Right, and that same empirical evidence shows that spatial violations are the more dangerous ones, and that's exactly why Zig prevents them. > but the comparision between Deno and Bun in the article What article? It seems that Bun has had one CVE. If you're talking about undefined behaviour you're, again, making an unjustified extrapolation from it to security. Some undefined behaviour leads to easily exploitable vulnerabilities, some does not. It's true that in the presence of UB, the compiler could hypothetically do anything, but to get a dangerous vulnerability it has to actually do something that's exploitable, and when we look at vulnerabilities caused by UB, we see that some kinds are more dangerous than others because of that. BTW, this touches on something that is sometimes misunderstood about UB. UB is defined with respect to a language specification, i.e. in the presence of UB, the language specification does not assign a program a meaning, but the compiler certainly does, because machine code has no UB. The program with the UB needs to compile to an exploitable binary for a vulnerability to exist. > and that's where the sharp line is I agree it's a sharp intrinsic line, just as saying that Zig avoids macros is a sharp line, but the impact of that line is anything but sharp. To draw the practical conclusion from it you don't follow the findings, but ignore them! > This doesn't really have anything to do with my point that the CVE list does not provide evidence to dismiss temporal memory safety as irrelevant I wasn't dismissing it as irrelevant. I was saying that if Rust's value is in eliminating dangerous vulnerabilities, then Zig has that value, too, and the difference between them isn't large on that particular front. > are not in the same league of program correctness Software correctness is something I've been dealing with and writing about for many years, especially formal verification (https://pron.github.io https://pron.github.io), and I can tell you that you're downright wrong on that. That "more sound guarantees is always the most effective form of improving correctness" is something we know (at least since the nineties) not to be generally true, which is also why the field is looking more and more into unsound methods. For example, Rust and Zig are more likely to effectively write correct programs than ATS, even though ATS is "in a different league" from both of them when it comes to sound guarantees. We know that sound guarantees can help, but that their cost matters a lot. We also know that reviews and tests and dynamic verification are very effective, sometimes more than sound guarantees. Rust proponents are free to speculate that, ultimately, Rust's approach leads to more correctness than Zig, and they can base that belief on some findings, and Zig proponents can do exactly the same in the opposite direction, also based on other findings, but both are speculations. People are free to choose which they are more inclined to believe, but the question isn't settled. > This lines up with my own experience; software I write using Rust is far easier to get right, more reliable, and easier to successfully maintain and refactor than anything else I've done. I'm not doubting that that's your experience. I'm saying we have no evidence that it's universal, likely to be universal etc. (and I know of some opposite experiences with Rust). Sometimes certain languages just click with certain people, but we can't extrapolate without more observation. > "there's a rather small difference between Rust and Zig" simply isn't true. The correctness difference between the two is unknown. It could be small or large and in either direction. The intrinsic differences are, of course, known, but don't really help reach an objective preference. My point was only that if we judge Rust by the vulnerabilities it soundly eliminates, then Zig is not far on that particular metric, and it's certainly much closer to Rust than to C.