5 ms·

> shows you're really not familiar with the PL design space (which is fine actually but you should probably not be arguing about academic domains you're not fam

by pron 4y ago

> shows you're really not familiar with the PL design space (which is fine actually but you should probably not be arguing about academic domains you're not familiar with). Oh, I'm familiar enough (my job requires me to be), but I wanted to list languages people here have heard about. Also, I'm not arguing about an academic domain. Having spent just the other night at a gathering with PL researchers in the UK, some interested in Zig, I know that even if we restrict the discussion to academia alone there is absolutely no consensus over the matter. It is an empty and false assertion, plain and simple. Also, let's not forget that Rust leans quite heavily on a garbage collector, too, albeit a rather crude one. > The idea that Rust may cause more bugs than it avoids is backed by zero evidence. I never claimed that it does. I said we don't know which approach leads to more correct software, and that anyone who says we do is simply unfamiliar with the field or misleading. I explain more below. > that “maybe Rust some unknown type of bugs we cannot be sure” is a fallacy That's not what I meant at all. Just as an example of things that Rust's design could adversely affect to the point of adversely affecting correctness, consider two techniques that have proven extremely valuable in improving software correctness: code reviews and tests. A complex language with a lot of implicitness, long compilation time, and possibly longer code-writing time, can slow down or hinder these two techniques. Those issues are related to why so many in software correctness research today focus on reducing soundness; soundness has a cost of slowing down very effective unsound techniques, and given that full-soundness is something most have given up on, whether the price is worth it is always a hard question with no easy answers. > Zig doesn't particularly address “correctness”, more than any typical language... I think it does, and Zig's designer thinks so too (in the sense that he's designing the language and it tools with correctness as a primary goal) -- I don't know if it's more than any "typical" language (working on a "typical" language myself and caring a lot about correctness, too), but certainly not to any lesser extent than Rust. In particular, there's a very strong emphasis on explicitness over explicitness (no hidden control flow, local reasoning) and there's a strong emphasis on fast compilation and good testing support (including a design that makes isolating units and testing them easier) to facilitate faster and more rigorous testing. Those who arrive at correctness from academic PL are often unfamiliar with such reasoning, which is now increasingly more common in formal methods research where the power of unsoundness is now appreciated. > There is no trade-off in correctness between those two I gave an example above that explains why some people think there could well be. No one can claim that either Zig or Rust yield more correct software, because we really don't know. > One can argue that “programming mistakes” ... That's not the argument at all. Memory errors are, indeed, both tricky and dangerous, and it is important to avoid them, but not at the expense of missing other, equally tricky and equally dangerous bugs. > If you want to see “Zig safety story” in action, have a look at the only commercial user of the language, and go search for “segfault” in the github issues… If you choose to eliminate bugs of class Y, you'll have none of them, and if you don't -- you will. This has no bearing at all on the question of overall correctness, which is what memory safety ultimately aims to serve. That is why there's no consensus over it.

littlestymaar 4y ago
> Also, let's not forget that Rust leans quite heavily on a garbage collector, too, albeit a rather crude one. How do you want anyone to take any your words seriously when saying things like this… Rust has reference-counting primitives in its standard libraries, but saying in “leans heavily” on it is a “very original” take (in fact, Rust leans more on “epoch-based memory reclamation” than it does on reference counting, but even if you had that in mind, it's still quite far from “leaning heavily”). > That's not what I meant at all. Just as an example of things that Rust's design could adversely affect to the point of adversely affecting correctness, consider two techniques that have proven extremely valuable in improving software correctness: code reviews and tests It “could”, in the same sense that “vaccine could cause autism” or “the US could never have put men on the moon and staged the moon landing in Hollywood” > I think it does, and Zig's designer thinks so too Interestingly enough, you spend much, much, more time talking about it than himself… > I gave an example above that explains why some people think there could well be. No one can claim that either Zig or Rust yield more correct software, because we really don't know. So the gist of your argument is that we don't know because for “some reason” Rust could make testing (this is ironic when you know how much of an improvement Rust testing story is compared to most languages) and code review less practical, to a point where it would more than compensate for a class of bug that have empirically proven really really hard to avoid with conventional methods like testing, code review or runtime tooling. Wonderful. > If you choose to eliminate bugs of class Y, you'll have none of them, and if you don't -- you will. This has no bearing at all on the question of overall correctness, which is what memory safety ultimately aims to serve. That is why there's no consensus over it. I was referring to this quote of yours above: “Zig has a pretty good memory safety story”. Which is empirically not so good.
- pron 4y ago
  > It “could”, in the same sense that “vaccine could cause autism” No. The claim "design with tradeoffs X leads to more correct programs than design with tradeoffs Y" is the one that requires evidence. The null hypothesis is that it doesn't. > Interestingly enough, you spend much, much, more time talking about it than himself… As I said, software correctness is my thing. When I saw Zig's brilliant, revolutionary design, I thought, wow, that's a powerful and interesting approach to software correctness. I thought pretty much the same when I saw Rust's design. My aesthetic preferences lean toward simpler languages, just as others' lean toward a more refined type system, but both of these languages make correctness a major focus of their design, they go after it in very different but equally interesting and novel ways, and it will be fascinating to learn which, if any, can achieve better correctness. However, anyone who says we already know is not telling the truth, and probably has a shaky understanding of the subject. > So the gist of your argument is that we don't know No. The reason we don't know is that we don't have evidence one way or another. I gave you one example as an intuition for why your hypothesis might be false. > I was referring to this quote of yours above: “Zig has a pretty good memory safety story”. Which is empirically not so good. You're saying it's not good because it doesn't try to completely eliminate such errors? That's called begging the question. Now, you can say many things about me, but when talking about technical subjects I try pick my words precisely. I'll gladly keep discussing the substance of the matter -- I've devoted a lot to it and I care deeply about it (look at my blog) -- but if you're trying to poke at my words you will most likely waste both our time. Yes, Zig has a pretty good memory safety story. It's a combination of sound spatial safety, precise pointer tracking, as well as some tools, to make catching temporal safety issues easier. It's not only a pretty good story, it's also interesting and rather novel one -- like Rust's -- only its particulars are very different. Zig's memory safety story is not perfect because the cost of perfection, Zig's philosophy believes, is too high, to the point of working against the goal of correctness. There are two relevant open questions: If correctness is all you care about, what price should you pay for memory safety? And what if you also care about other things? I don't know the answer to these questions -- nobody does -- but we need both Zig and Rust to help us learn.

by pron 4y ago

littlestymaar 4y ago

> Also, let's not forget that Rust leans quite heavily on a garbage collector, too, albeit a rather crude one. How do you want anyone to take any your words seriously when saying things like this… Rust has reference-counting primitives in its standard libraries, but saying in “leans heavily” on it is a “very original” take (in fact, Rust leans more on “epoch-based memory reclamation” than it does on reference counting, but even if you had that in mind, it's still quite far from “leaning heavily”). > That's not what I meant at all. Just as an example of things that Rust's design could adversely affect to the point of adversely affecting correctness, consider two techniques that have proven extremely valuable in improving software correctness: code reviews and tests It “could”, in the same sense that “vaccine could cause autism” or “the US could never have put men on the moon and staged the moon landing in Hollywood” > I think it does, and Zig's designer thinks so too Interestingly enough, you spend much, much, more time talking about it than himself… > I gave an example above that explains why some people think there could well be. No one can claim that either Zig or Rust yield more correct software, because we really don't know. So the gist of your argument is that we don't know because for “some reason” Rust could make testing (this is ironic when you know how much of an improvement Rust testing story is compared to most languages) and code review less practical, to a point where it would more than compensate for a class of bug that have empirically proven really really hard to avoid with conventional methods like testing, code review or runtime tooling. Wonderful. > If you choose to eliminate bugs of class Y, you'll have none of them, and if you don't -- you will. This has no bearing at all on the question of overall correctness, which is what memory safety ultimately aims to serve. That is why there's no consensus over it. I was referring to this quote of yours above: “Zig has a pretty good memory safety story”. Which is empirically not so good.

pron 4y ago
> It “could”, in the same sense that “vaccine could cause autism” No. The claim "design with tradeoffs X leads to more correct programs than design with tradeoffs Y" is the one that requires evidence. The null hypothesis is that it doesn't. > Interestingly enough, you spend much, much, more time talking about it than himself… As I said, software correctness is my thing. When I saw Zig's brilliant, revolutionary design, I thought, wow, that's a powerful and interesting approach to software correctness. I thought pretty much the same when I saw Rust's design. My aesthetic preferences lean toward simpler languages, just as others' lean toward a more refined type system, but both of these languages make correctness a major focus of their design, they go after it in very different but equally interesting and novel ways, and it will be fascinating to learn which, if any, can achieve better correctness. However, anyone who says we already know is not telling the truth, and probably has a shaky understanding of the subject. > So the gist of your argument is that we don't know No. The reason we don't know is that we don't have evidence one way or another. I gave you one example as an intuition for why your hypothesis might be false. > I was referring to this quote of yours above: “Zig has a pretty good memory safety story”. Which is empirically not so good. You're saying it's not good because it doesn't try to completely eliminate such errors? That's called begging the question. Now, you can say many things about me, but when talking about technical subjects I try pick my words precisely. I'll gladly keep discussing the substance of the matter -- I've devoted a lot to it and I care deeply about it (look at my blog) -- but if you're trying to poke at my words you will most likely waste both our time. Yes, Zig has a pretty good memory safety story. It's a combination of sound spatial safety, precise pointer tracking, as well as some tools, to make catching temporal safety issues easier. It's not only a pretty good story, it's also interesting and rather novel one -- like Rust's -- only its particulars are very different. Zig's memory safety story is not perfect because the cost of perfection, Zig's philosophy believes, is too high, to the point of working against the goal of correctness. There are two relevant open questions: If correctness is all you care about, what price should you pay for memory safety? And what if you also care about other things? I don't know the answer to these questions -- nobody does -- but we need both Zig and Rust to help us learn.