3 ms·

> because by our definition of “knowing”, we never get to know anything. I was talking about the common scientific method. You can define "know" as "the vast m

by pron 4y ago

> because by our definition of “knowing”, we never get to know anything. I was talking about the common scientific method. You can define "know" as "the vast majority of the target community is sufficiently convinced that something is true." > and use of Zig in the wild shows that the issue is unsurprisingly very common in Zig, as it is in C You've seen absolutely no such thing. > So, yes we cannot be sure that there aren't second orders or third orders effects that makes Rust less than optimal and compensate for this massive difference, but there exist no convincing list of such hypothetical effects that could have a significant impact in Rust's ability to build correct software I am not doubting Rust's ability to build correct software, just the claim that it's obviously the best approach. > Rust has a strong emphasis on explicitness I think you don't understand what "explicitness" means in this context, as Rust relies on more implicitness than most popular languages. > So have clear evidences of a strong first order effect in favor of Rust, and no compelling evidences for adverse higher orders effects, that's what our current knowledge is. Taken as is, you're once again claiming that your belief requires no evidence. Taken more charitably, what you're saying is that you believe it because it is very obvious to you. In that case, either it will be easily verified by the evidence and rather quickly, or it will be shown wrong just like previous "obvious" beliefs regarding software correctness. What you can't do is is demand evidence from others because what's obvious to them isn't obvious to you, and at the same time claim that what's obvious to you and isn't obvious to others should be assumed true. > because Haskell cannot really pinpoint a significant edge over other languages I don't know if you're aware how this kind of argumentation sounds to others, but are you really comfortable making such arguments to support what is a scientific claim? Not only did Haskell supporters say the exact same thing (their edge over, say, Clojure was, of course the type system) but even after time and again we see how complex this subject is, how elaborate the interactions, you make an argument that is not much stronger than, "well, I have more money in my wallet than you, and since I can't immediately see any indication that you have more in your bank we can safely assume I'm richer than you." > But Zig carries a significant burden in that regard And Rust carries a significant burden, too: it hinders, in comparison, the two most effective assurance methods we have, tests and code reviews. Just as importantly, too many people find complex languages unappealing, and so the impact a language that not many people would use cannot be large. Now, I am not trying to convince you that you're wrong, just that different things are obvious to different people, and unless something is obvious to pretty much everyone -- which clearly isn't the case here -- you cannot expect others to just accept your belief, however strongly you believe it, while demanding evidence from them for not accepting it. The fact is that however obvious it may seem to you, other do not not seem to think that it is obvious that Rust leads to more correct software than, say, Zig. If you're trying to convince others of that, then you have to support it by their standard, not yours (of "faith alone suffices"). I would suggest not repeating arguments that are not only logically weak but have failed just recently, and prefer empirical evidence. But hey, do what you want, and if you believe that everyone should be convinced or that perhaps everyone is already convinced -- that's fine, too. Just don't be surprised when others find such assertions of faith somewhat cultish and not a good look for programmers. And you know what? If you think your argument is so scientifically convincing, try writing a science paper making the claim that Rust yields to better correctness than Zig. Until then, programmers will use whatever language we find most aesthetically pleasing, enjoyable, or profitable.

littlestymaar 4y ago
It's funny to read you talking about “beliefs” and “cult” while at the same time being in such a denial: > You've seen absolutely no such thing. 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. And as an epistemological conclusion to this discussion, I should note that while you use “beliefs” pejoratively, but “knowledge” is in fact nothing more than rationally founded “beliefs” that's open to perpetual questioning ;). Here you just refuse to accept to even think about the rational arguments because they go against your beliefs, hence the reluctance to address the arguments when I've exposed them, falling back to parroting your common sense over and over.
- kristoff_it 4y ago
  FYI the Zig compiler that people are still using today is the C++ one. The self-hosted compiler hasn't been released yet. There's some Zig code running today in the C++ compiler, but hasn't been there for the full life of the project and isn't the main source of bugs by far. To this day I think the top 3 popular Zig projects are Bun, as you mentioned, then River [1] and TigerBeetle [2]. [1] https://github.com/riverwm/river https://github.com/riverwm/river [2] https://github.com/tigerbeetledb/tigerbeetle https://github.com/tigerbeetledb/tigerbeetle Up to you to decide how fine is the situation in those projects.
  - littlestymaar 4y ago
    Most of the recent segfaults that have been fixed in Zig where Zig related, not caused by C++. (Without even mentioning the segfault in the std lib). And about tigerbeetle, this gives you an idea of how compelling the zig memory safety story is today: > All memory must be statically allocated at startup. No memory may be dynamically allocated (or freed and reallocated) after initialization. And then both river and bun have their shares of segfaults, with river looking substantially better than bun, but it suspect it also has much less usage in the wild. Overall, it looks pretty much like C as I said.
- 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.

by pron 4y ago

littlestymaar 4y ago

It's funny to read you talking about “beliefs” and “cult” while at the same time being in such a denial: > You've seen absolutely no such thing. 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. And as an epistemological conclusion to this discussion, I should note that while you use “beliefs” pejoratively, but “knowledge” is in fact nothing more than rationally founded “beliefs” that's open to perpetual questioning ;). Here you just refuse to accept to even think about the rational arguments because they go against your beliefs, hence the reluctance to address the arguments when I've exposed them, falling back to parroting your common sense over and over.

kristoff_it 4y ago
FYI the Zig compiler that people are still using today is the C++ one. The self-hosted compiler hasn't been released yet. There's some Zig code running today in the C++ compiler, but hasn't been there for the full life of the project and isn't the main source of bugs by far. To this day I think the top 3 popular Zig projects are Bun, as you mentioned, then River [1] and TigerBeetle [2]. [1] https://github.com/riverwm/river https://github.com/riverwm/river [2] https://github.com/tigerbeetledb/tigerbeetle https://github.com/tigerbeetledb/tigerbeetle Up to you to decide how fine is the situation in those projects.
- littlestymaar 4y ago
  Most of the recent segfaults that have been fixed in Zig where Zig related, not caused by C++. (Without even mentioning the segfault in the std lib). And about tigerbeetle, this gives you an idea of how compelling the zig memory safety story is today: > All memory must be statically allocated at startup. No memory may be dynamically allocated (or freed and reallocated) after initialization. And then both river and bun have their shares of segfaults, with river looking substantially better than bun, but it suspect it also has much less usage in the wild. Overall, it looks pretty much like C as I said.
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.