4 ms·

> and he's arguably correct on that front: no mainstream (even in the broadest sense) language that ever came after C++ was memory-unsafe. I don't understand

• littlestymaar 4y ago
  > Of all the low-level languages developed after C++, including D, Rust, Zig, Odin, and JAI, the majority aren't memory safe. It's funny because you've included a language built around garbage collection (D), and a language that doesn't really exist yet (Jai, which is actually a placeholder name). Btw, this list (which basically contains only names we can see every once in a while on HN) 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). > I know, but the reason it does so is as a means to an end. The reason why anyone wants memory safety is that it eliminates certain classes of bugs that can be quite harmful. The reason why we may not want memory safety is that sometimes it can come at the cost of other bugs, overall not helping correctness. Anyway, software correctness is a complex issue, and it is not currently known whether Rust's approach or Zig's -- if either -- is more effective at achieving correctness. The idea that Rust may cause more bugs than it avoids is backed by zero evidence. Is Rust worth it, from a engineering team perspective, given its other constraints (low number of trained practitioners, slow compilation time, or even an hypothetical productivity cost) is a fine question, especially when I see Rust being used for back-end roles where other entrenched languages are doing fine, but claiming that “maybe Rust some unknown type of bugs we cannot be sure” is a fallacy (same fallacy applied to a different context: “climate is a complex issue, maybe there's some non-anthropic cause for global warming”). Zig doesn't particularly address “correctness”, more than any typical language: it doesn't address “design errors” more than Rust, and is arguably addressing less “programming mistakes”. There is no trade-off in correctness between those two (Rust is trading learning curve against correctness, and it might even trade productivity for correctness, but it's not trading one kind of correctness in favor of another). One can argue that “programming mistakes” are unimportant overall, because they get ironed out easily, and that it's a matter of team experience and proficiency, and in fact in managed languages it may be true, and that would explain why functional programming never took off, but when in comes to memory management, we've had enough CVEs to show that no, programming mistakes don't get ironed out easily. 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…
  • 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.