3 ms·
> Just go ahead, grab a few popular projects in Zig (for instance Bun or the zig compiler) and their issue tracker and see how fine the situation is. I don't u
by pron 4y ago
> Just go ahead, grab a few popular projects in Zig (for instance Bun or the zig compiler) and their issue tracker and see how fine the situation is.
I don't understand. Zig's approach to correctness means giving up on some sound memory safety guarantees in exchange for benefits elsewhere, i.e. it prefers some memory bugs in exchange for fewer others. What conclusion is it, again, that you're trying to draw from the existence of such bugs, and how do you conclude that they occur with the same frequency as in C? Your claim is statistical and I don't see what statistical method you used on the bugs you saw to support it.
> Here you just refuse to accept to even think about the rational arguments because they go against your beliefs
My only relevant belief here is that we do not have evidence supporting the claim that Rust yields more correct software than Zig, and the only rational argument that could go against that belief is the presentation of such evidence. I have no belief regarding which of Rust or Zig yields more correct programs (if either). The reason I have no such beliefs is that I know how complex and unintuitive software correctness is, and both languages have chosen interesting and novel approaches that are not directly comparable based on prior evidence, and so they themselves will have to produce that evidence over time.
Because you asked me to address your arguments (which aren't such a presentation of empirical evidence), the reason why they're unconvincing is as follows. When comparing both Zig and Rust to C++, it is reasonable to accept the claim that they both lead to more correct programs. Why? Because the claim is that they both dominate C++, i.e. they catch all the bugs that you'd catch in C++ plus more. They both make more sound guarantees, and their readability is no worse.
But that is not the same argument used to compare Rust and Zig, because they're incomparable: Rust makes more sound guarantees but it's more complex and requires more non-local reasoning to understand (and might appeal to fewer people), while Zig makes fewer sound guarantees but in exchange it strives to be easier to understand (and to appeal to more people). I.e., the argument for comparison here is not one of dominance but one of a more profitable tradeoff. Your claim that we should value the "hard", formal soundness aspects more than the "softer", informal, aspects is unconvincing because the history of software correctness shows it's a mistake to do so -- "soft" correctness techniques have proven at least as powerful as hard, formal ones, if not more. So, when the tradeoff involves both the formal and informal components of software correctness -- an interaction known to be complex and surprising -- it cannot be settled by simple argumentation, but only by empirical evidence.
That is my one and only argument: because the two languages are not directly comparable as they consciously make different tradeoffs in their chosen paths for correctness, comparing their outcomes requires an empirical test.
Since I've written about software correctness quite a bit over quite a few years now, I think the claim that I am not open to reason in that area is easily disproven by the available material. On the other hand, when someone tries to convince other professionals and fails to do so, saying "you're not convinced just because you're not open", does not lend more credence to the argument. I guess we could call that, "proof by plea", which is not, as far as I know, established as a legitimate form of knowledge gathering in science. But, like I said before, if you think the problem is me and not the strength of your argument, you can put that to the test: publish a scientific paper arguing that Rust leads to more correct programs than Zig (not C or C++), and see how many are convinced by it. If I'm the only holdout, then I'd know the problem is me; if not, then you'd know that the persuasive power of your argument is lacking.
- littlestymaar 4y ago> Why? Because the claim is that they both dominate C++, i.e. they catch all the bugs that you'd catch in C++ plus more. They both make more sound guarantees, and their readability is no worse. You're talking about rigor but you keep making these laughably strong claims. This one is an extraordinary one, and it's most likely also false just because I'm pretty convinced that copy/move constructors can make some (rare) patterns much simpler and as such avoid bugs in practice. It's not clear if copy/move constructors are a net win, and the overall effect is almost certainly minimal anyway, but that's enough to refute the domination claim. > I don't understand. That's the key. And you don't want to understand, I'm afraid.
- pron 4y agoI have no idea what you're talking about. My one and only "claim" -- a simple statement of fact, really -- is that we lack any empirical evidence that Rust yields more correct programs than Zig, and that because the two languages consciously make different tradeoffs, they are not directly comparable, and so such empirical evidence is needed. That's it. Everything else is just a response to you asking for more context and examples, as well as explanations for why your arguments are so unconvincing, which you then misunderstand as further claims that they are not (e.g. I do not claim that either Zig or Rust yields more correct programs than C/C++). In fact, I do not claim that any language yields more correct programs than any others (not that I don't think that could be true, I'm just hesitant to make such claims). All I did was explain why such an argument would be more convincing than the argument you're making for Rust vs. Zig. Seems like we're stuck in a circle where you can't understand what I'm saying and I can't understand what you're saying. In any event, we've gone full meta. Like I said, if you think I am the problem, that can be easily tested. Put your argument in a paper so that it can be properly critiqued. This way you'd at least know if it's me who doesn't want to understand or that your arguments are just not very convincing. If most software correctness people find it convincing -- yay for you; if not, you'll learn how to make your argument more convincing, so also yay for you.