Hacker News Reader

Comment by kstenerud | Hacker News Reader

> First, their argument for Rust (and against C) because of memory safety implies that they have not done due diligence in finding and fixing such bugs.

No, it implies that finding such bugs is exponentially harder in C than it is in other languages. Eventually you reach so far up the diminishing returns curve that you simply are able to accomplish more in one language with your time on Earth than you can in another. This is a numbers game, and C loses out to safer competitors when it comes to bugs.

The due diligence that these developers are doing is a meta-analysis that has gone over your head.

> And with my bc, I did my due diligence with memory safety. I fuzzed my bc and eliminated all of the bugs.

That's a pretty absolute claim. And one I doubt.

I'll save my trust for people humble enough to understand the limitations of technologies and themselves.

View on HN

Author here.

If you doubt my claims about my bc, I suggest you break it and post it here. Embarrass me.

Yes, I am throwing down the gauntlet because I am that confident in my work. Prove me wrong with actual data.

> all of the bugs

Probably meant all of the reported bugs, given the context.

Which makes it all the worse, because he's using that as "proof" that he has done more due diligence than these other devs, and suggesting that they could achieve just-as-good-or-better results by emulating him (which is provably false given the nature of C vs rust when it comes to bugs).

For a calculator it may be no huge deal to have such a cavalier attitude. But for cryptography, bugs are considerably more important as the threat model isn't even in the same league.

Author here.

The fact that I _could have had_ a cavalier attitude towards C memory safety, but didn't, shows (I believe) just how much the Cryptography authors fell short because _they were writing crypto_. If anything, they should have surpassed the amount of due diligence that I did on bc, but they didn't.

It's easy to look back in hindsight and take potshots based on everything someone did wrong. There's not a project out there where you couldn't do this.

I took a quick look over the thread, and TBH I find the authors' reasons and explanations compelling, logical, and respectful (their FAQ, the fact that they polled the users almost a year ago, the fact that they announced their intentions in advance, and how to deal with the impending changes). I suggest you re-think your approach; this won't reflect well.

Your arguments are fair.

However, can you tell me more what you mean about rethinking my approach? I am not sure what approach you are referring to.

I mean escalating a minor dust-up into a blog post about their wrongs, and then further pushing it in a worldwide forum (HN).

I don't mean to be rude, but as a disinterested third party, the optics of all of this and your handling of a disagreement reflect badly upon you. At some point in the future after you've cooled off, you'll probably delete the post (but better sooner than later!)

I actually don't see what you said as being rude, just honest, and I appreciate that.

I actually let myself cool down before I wrote the post. I was going to write the post right after I saw the GitHub issue, but I sat on it for awhile, thinking through my thoughts.

It's unfortunate that such a dust-up (which wasn't minor, by the way; it got published in LWN, see https://lwn.net/Articles/845535/) was a perfect way to make arguments against Rust that I have wanted to make.

And I wanted to make them because if Rust can be as portable as C, I would LOVE that!

Reply on news.ycombinator.com