Game Jam 2 Results • Hacker News Board

Re: Game Jam 2 Results

#181

Post by pron » Fri, Sep 16, 2022, 7:14 AM UTC

littlestymaar wrote: post #180

pron wrote: post #178

Earlier quoted context omitted.

> You need to know when to free memory, so you explicitly need to reason about it, just like in Rust Obviously! But my point was that that reasoning isn't additive. If an algorithm is complex enough that you have to carefully reason about its object lifetime, then you might have to carefully reason about it even if you're guaranteed to get the lifetime right. Or, rather, sometimes you might, sometimes maybe not, and…

> Obviously! But my point was that that reasoning isn't additive That's a very very strong claim without any supporting argument. And I'd be very surprised if it was true. (the success of the Stylo project on Firefox is a significant counter-example for instance). > -- at a price. once again, the abstract “price” is invoked, without any characterization… thousands of words later, we still don't know what price you're…

> 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?

Re: Game Jam 2 Results

#182

Post by littlestymaar » Fri, Sep 16, 2022, 12:40 PM UTC

pron wrote: post #181

littlestymaar wrote: post #180

Earlier quoted context omitted.

> Obviously! But my point was that that reasoning isn't additive That's a very very strong claim without any supporting argument. And I'd be very surprised if it was true. (the success of the Stylo project on Firefox is a significant counter-example for instance). > -- at a price. once again, the abstract “price” is invoked, without any characterization… thousands of words later, we still don't know what price you're…

> 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…

> > 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.

Re: Game Jam 2 Results

#183

Post by pron » Fri, Sep 16, 2022, 5:34 PM UTC

littlestymaar wrote: post #182

pron wrote: post #181

Earlier quoted context omitted.

> 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…

> > 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”…

> 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.

Re: Game Jam 2 Results

#184

Post by mzl » Fri, Sep 16, 2022, 8:18 PM UTC

Ygg2 wrote: post #175

skohan wrote: post #172

Earlier quoted context omitted.

> Saying it's not perfectly safe is sophistry. Nothing is perfectly safe, but you still don't hand out your sensitive bank information to random person on the Internet/street/etc. You want to make a nuanced argument that calculated unsafety is better than general unsafety, but you don't want to accept a nuanced argument that Rust's safety tools maybe a detriment in some use-cases. > Assume data race happen. Would you…

> You want to make a nuanced argument that calculated unsafety is better than general unsafety, No. I'm making a simple argument. More safety is better than less safety. You're trying to move argument that since perfect safety is impossible it's not worth pursuing. This is the sophistry part. > It depends on the use-case. No it doesn't. Debugging 30k lines is always going to take more than 3/30/300 lines especially w…

> There are HFT systems using Java, few were on HN even.

The HFT systems I know about in Java are mostly not recognizable as Java to most Java programmers. They use static allocation of all data making sure that there is no risk of a GC interrupt and have a fixed set of threads that have assigned cores.

It is sometimes a reasonable way to build a system, but very seldom.

Re: Game Jam 2 Results

#185

Post by littlestymaar » Fri, Sep 16, 2022, 9:06 PM UTC

pron wrote: post #183

littlestymaar wrote: post #182

Earlier quoted context omitted.

> > 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”…

> 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…

> 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.

[…]

> 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.

You should definitely take epistemology classes on coursera or elsewhere, because by our definition of “knowing”, we never get to know anything.

And unfortunately this “but we cannot know it's too complex” is way too common nowadays, from climate change to pandemic management “we don't know” is a convenient fallacy. There are key things that we actually do know :

- that Rust is memory safe while Zig isn't (not even from a spacial perspective because there are escape hatches).

- that memory safety is a deep issue and tracking object lifetime by hand isn't something humans are good at, at all. (and use of Zig in the wild shows that the issue is unsurprisingly very common in Zig, as it is in C).

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 (to take your examples about legibility and testing, Rust has a strong emphasis on explicitness and incremental builds are more than fast enough for efficient testing, so there's little margin for gains on these fronts).

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.

That's a big difference with your Haskell example, because Haskell cannot really pinpoint a significant edge over other languages, it's more a collection of convenient little things, so the improvement is much more vulnerable to higher order effects. The same could be said if we had to compare Rust and Java for instance: I much prefer use Rust than Java because there are many things that I like but at the same time there are little things that are decisively in favor of Rust (Send and Sync trait for compile-time thread safety is nice, but really workload dependent) so I'd be very wary of saying that Rust leads to more correct code than Java.

But Zig carries a significant burden in that regard (and I believe it should really think about introducing a borrow-checker-like in its design before it's too late and compatibility with existing code makes it impossible, while eschewing the whole ML-style functional stuff that Rust has, because that part is definitely in the “nice to have but not really significant” category).

Re: Game Jam 2 Results

#186

Post by pron » Sat, Sep 17, 2022, 8:25 AM UTC

littlestymaar wrote: post #185

pron wrote: post #183

Earlier quoted context omitted.

> 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…

> 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. […] > 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. You should definitely take epistemology…

> 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.

Re: Game Jam 2 Results

#187

Post by littlestymaar » Sat, Sep 17, 2022, 8:52 PM UTC

pron wrote: post #186

littlestymaar wrote: post #185

Earlier quoted context omitted.

> 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. […] > 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. You should definitely take epistemology…

> 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…

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.

Re: Game Jam 2 Results

#188

Post by kristoff_it » Sun, Sep 18, 2022, 12:53 AM UTC

littlestymaar wrote: post #187

pron wrote: post #186

Earlier quoted context omitted.

> 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…

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 “knowledg…

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 [2] https://github.com/tigerbeetledb/tigerbeetle

Up to you to decide how fine is the situation in those projects.

Re: Game Jam 2 Results

#189

Post by littlestymaar » Sun, Sep 18, 2022, 6:52 AM UTC

kristoff_it wrote: post #188

littlestymaar wrote: post #187

Earlier quoted context omitted.

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 “knowledg…

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…

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.

Re: Game Jam 2 Results

#190

Post by pron » Sun, Sep 18, 2022, 10:52 AM UTC

littlestymaar wrote: post #187

pron wrote: post #186

Earlier quoted context omitted.

> 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…

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 “knowledg…

> 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.