3 ms·

> That's a very very strong claim without any supporting argument. I'm afraid you completely misunderstand my position. I'm merely pointing out that because we

by pron 4y ago

> That's a very very strong claim without any supporting argument. I'm afraid you completely misunderstand my position. I'm merely pointing out that because we know that more soundness is not always better, the claim that Rust is more effective than Zig is not obviously true. I'm not saying it necessarily isn't. We simply don't know yet. > the success of the Stylo project on Firefox is a significant counter-example for instance A counter-example for what? No one is saying that Rust doesn't work well or that it doesn't offer more correctness than C++. > You've shown a real difficulty so far to substantiate your argument with anything concrete But I don't have any hypothesis to substantiate. I'm pointing out what we don't know. I did give concrete examples for cases where unsoundness worked better than soundness, but because we already know that the most effective approach is not on either end, we cannot extrapolate from any specific comparison to another. If someone wants to say language X works better for correctness than Y, they must compare X and Y, not X and Z. But I'm not making any such claim about Rust and Zig. > Now if Zig comes and wants to challenge it[1], fine but the burden of the proof is on Zig. No one is claiming that Zig works better than Rust, no one wants to "challenge" Rust with Zig, and no one is challenging the claim that Rust works better than C++. I want both languages to challenge the status quo. > But Rust is especially well-placed in that regard Of course. Rust and Zig are both well-placed in that regard, and people who care about correctness want both: First, we don't know which, if any, works better than the other. Second, even if one of them does work better than the other, I think it's pretty uncontroversial that they both provide better correctness than C++ (they both provide stronger guarantees, and neither is significantly more complex than C++). But because it seems that there are people who don't like Rust, and there are people who don't like Zig, software will be better served by having both. Those who say they want Zig to not exist (like pcwalton) are not serving software correctness. I want Rust; I want Zig. We don't know what works best, neither of them is for everyone, so we need both. > in fact this has never been an explicit goal of Zig's creator, who just want to make his programming language without bothering anyone else Indeed. More correctness than C and C++ is, of course, one of Zig's goals; more correctness than Rust isn't. But more correctness than Zig isn't a goal of Rust, either. We want both to exist, if only because different people would prefer different languages, and both are probably improvements over the status quo. It's pcwalton who said he doesn't think Zig should exist. So let's not bother anyone else by making unsubstantiated claims about which is better, and certainly not by saying that the other shouldn't exist. Okay?

littlestymaar 4y ago
> > That's a very very strong claim without any supporting argument. > I'm afraid you completely misunderstand my position. I'm merely pointing out that because we know that more soundness is not always better, the claim that Rust is more effective than Zig is not obviously true. I'm not saying it necessarily isn't. We simply don't know yet. This isn't in any way related to the claim that I qualified as “very strong”: you said “But my point was that that reasoning isn't additive”, which is a very strong claim and likely to be false. The Firefox team successfully shipping their multi-threaded CSS engine in Rust while they had failed to do so in two or three previous in C++ hints that implementing complex algorithms and at the same time having to be sure you don't mix things up with lifetime is harder than just implementing the same complex algorithm without having to think about mixing things up with lifetimes. The great shift towards Java in the 90s is also an indication of it. Taking the responsibility to manage memory manually is hard, very hard and adds a significant burden on the programmer. And this isn't “unknown”. > and certainly not by saying that the other shouldn't exist. Okay? Where in my comments can you find a single occurrence of this claim? I'm just arguing that at this point your reasoning of saying “we don't know which is better” is as fact-based as people arguing that “we don't know if vitamin D or Hydroxychloroquine are better than vaccines”. Zig doesn't have to be on par with Rust to have its right to exists, there's no point overselling with on the “correctness” argument that has never been its main stated motivation. And you, the “Java guy who doesn't like Rust” are practically the only one having this argument on HN, you should try leaving Rust and Zig alone for once. Anyway, you've long stopped giving arguments and have been parroting the same “we don't know” over and over and over without any attempt to add anything new to the discussion, so I'm not interested in pursuing. Too bad, I won't have a single example of how Rust incurs a cost in correctness, nor how Zig's design is so brilliant it will make thinking about memory more practical than C and avoid memory management to get in the way of correctness, so much virtual ink spent in vain.
- pron 4y ago
  > This isn't in any way related to the claim that I qualified as “very strong”: you said “But my point was that that reasoning isn't additive”, which is a very strong claim and likely to be false. You've misunderstood. I am not trying to make a claim about how reasoning works, but to give possible explanations for why assumptions that more soundness is always better often turn out wrong, i.e. how it could work. The question of why it is that we get such "surprising" outcomes in software correctness is interesting, but we until we get an answer to it, we just know that we get surprising answers. > I'm just arguing that at this point your reasoning of saying “we don't know which is better” is as fact-based This doesn't make sense at all. Not knowing is the default. Until there's conclusive evidence, the fact is that we don't know. > Too bad, I won't have a single example of how Rust incurs a cost in correctness I don't know that it does. I gave you several examples of how it might: reading it is hard as it has implicitness and compiling it takes long making testing more burdensome. Maybe there are other reasons, maybe there are none. Now, this is handwaving, but it's more than we need. It's okay to believe that Rust yields more correctness than Zig, the same amount, or less, but until we have empirical findings one way or the other, we don't know, even without any handwaving. > nor how Zig's design is so brilliant it will make thinking about memory more practical than C and avoid memory management to get in the way of correctness I explained that, too. Not only does Zig provide sound spatial memory safety -- which neither C nor C++ do -- but it also has precise pointers, i.e. you can soundly track where your pointers are, which is not the case in C/C++, where you can magically create bad pointers from good ones with pointer/array index arithmetic, or magically create pointers from non-pointers with silent casting (like unions). Zig, like Rust and GC languages has precisely tracked pointers. Good pointers can turn bad through user-after-free in Zig, but they can't be "born" bad as in C and C++. > Where in my comments can you find a single occurrence of this claim? Not in yours. In pcwalton. You've just tried inverting the rules of science by saying that if you assert something is true and someone else points out that it's an unsubstantiated hypothesis, the burden of proof is on them, thereby making your hypotheses true by default. Again, I think there can be a wide consensus that both Zig and Rust provide more correctness than C or C++ because they both make stronger sound guarantees and neither is worse at reasoning or testing than C++, but the question of whether any of them is more effective at correctness than the other is unknown, and unknowable until we empirically compare the two. That something is unknown is not a claim that requires proof; until we have proof for something -- we don't know. Here's what happened with Haskell: Some Haskellers kept insisting that Haskell yields more correctness than some other languages, and that that should be accepted as the null hypothesis until proven otherwise. Then there were a number of empirical tests that believed they'd be able to show it, and they couldn't find any large effect. So even after the empirical examination some Haskellers insisted their hypothesis should be taken as true by default, because the empirical tests weren't good enough. The result is that people who care to claim about correctness get sucked into these beliefs and not even empirical findings (or lack thereof) can shake them. That's not how we move correctness forward. Of course, Rust is not quite in the same position as Haskell because it hasn't been around the long, but it's important not to get too attached to religious beliefs that "this is the only way." Findings in software correctness frequently surprise us.

by pron 4y ago

littlestymaar 4y ago

> > That's a very very strong claim without any supporting argument. > I'm afraid you completely misunderstand my position. I'm merely pointing out that because we know that more soundness is not always better, the claim that Rust is more effective than Zig is not obviously true. I'm not saying it necessarily isn't. We simply don't know yet. This isn't in any way related to the claim that I qualified as “very strong”: you said “But my point was that that reasoning isn't additive”, which is a very strong claim and likely to be false. The Firefox team successfully shipping their multi-threaded CSS engine in Rust while they had failed to do so in two or three previous in C++ hints that implementing complex algorithms and at the same time having to be sure you don't mix things up with lifetime is harder than just implementing the same complex algorithm without having to think about mixing things up with lifetimes. The great shift towards Java in the 90s is also an indication of it. Taking the responsibility to manage memory manually is hard, very hard and adds a significant burden on the programmer. And this isn't “unknown”. > and certainly not by saying that the other shouldn't exist. Okay? Where in my comments can you find a single occurrence of this claim? I'm just arguing that at this point your reasoning of saying “we don't know which is better” is as fact-based as people arguing that “we don't know if vitamin D or Hydroxychloroquine are better than vaccines”. Zig doesn't have to be on par with Rust to have its right to exists, there's no point overselling with on the “correctness” argument that has never been its main stated motivation. And you, the “Java guy who doesn't like Rust” are practically the only one having this argument on HN, you should try leaving Rust and Zig alone for once. Anyway, you've long stopped giving arguments and have been parroting the same “we don't know” over and over and over without any attempt to add anything new to the discussion, so I'm not interested in pursuing. Too bad, I won't have a single example of how Rust incurs a cost in correctness, nor how Zig's design is so brilliant it will make thinking about memory more practical than C and avoid memory management to get in the way of correctness, so much virtual ink spent in vain.

pron 4y ago
> This isn't in any way related to the claim that I qualified as “very strong”: you said “But my point was that that reasoning isn't additive”, which is a very strong claim and likely to be false. You've misunderstood. I am not trying to make a claim about how reasoning works, but to give possible explanations for why assumptions that more soundness is always better often turn out wrong, i.e. how it could work. The question of why it is that we get such "surprising" outcomes in software correctness is interesting, but we until we get an answer to it, we just know that we get surprising answers. > I'm just arguing that at this point your reasoning of saying “we don't know which is better” is as fact-based This doesn't make sense at all. Not knowing is the default. Until there's conclusive evidence, the fact is that we don't know. > Too bad, I won't have a single example of how Rust incurs a cost in correctness I don't know that it does. I gave you several examples of how it might: reading it is hard as it has implicitness and compiling it takes long making testing more burdensome. Maybe there are other reasons, maybe there are none. Now, this is handwaving, but it's more than we need. It's okay to believe that Rust yields more correctness than Zig, the same amount, or less, but until we have empirical findings one way or the other, we don't know, even without any handwaving. > nor how Zig's design is so brilliant it will make thinking about memory more practical than C and avoid memory management to get in the way of correctness I explained that, too. Not only does Zig provide sound spatial memory safety -- which neither C nor C++ do -- but it also has precise pointers, i.e. you can soundly track where your pointers are, which is not the case in C/C++, where you can magically create bad pointers from good ones with pointer/array index arithmetic, or magically create pointers from non-pointers with silent casting (like unions). Zig, like Rust and GC languages has precisely tracked pointers. Good pointers can turn bad through user-after-free in Zig, but they can't be "born" bad as in C and C++. > Where in my comments can you find a single occurrence of this claim? Not in yours. In pcwalton. You've just tried inverting the rules of science by saying that if you assert something is true and someone else points out that it's an unsubstantiated hypothesis, the burden of proof is on them, thereby making your hypotheses true by default. Again, I think there can be a wide consensus that both Zig and Rust provide more correctness than C or C++ because they both make stronger sound guarantees and neither is worse at reasoning or testing than C++, but the question of whether any of them is more effective at correctness than the other is unknown, and unknowable until we empirically compare the two. That something is unknown is not a claim that requires proof; until we have proof for something -- we don't know. Here's what happened with Haskell: Some Haskellers kept insisting that Haskell yields more correctness than some other languages, and that that should be accepted as the null hypothesis until proven otherwise. Then there were a number of empirical tests that believed they'd be able to show it, and they couldn't find any large effect. So even after the empirical examination some Haskellers insisted their hypothesis should be taken as true by default, because the empirical tests weren't good enough. The result is that people who care to claim about correctness get sucked into these beliefs and not even empirical findings (or lack thereof) can shake them. That's not how we move correctness forward. Of course, Rust is not quite in the same position as Haskell because it hasn't been around the long, but it's important not to get too attached to religious beliefs that "this is the only way." Findings in software correctness frequently surprise us.