[tptacek]

It's not just the Rust community. I don't especially like Rust, but I fully buy into the argument that code written in memory-unsafe languages is materially less safe than code that is. There are plenty of memory-safe options, and rewriting software to be memory safe --- especially when there's a clear, simple common case to seize on --- is a positive step for Internet safety.

[ok_dad]

I totally get that, but my stance on the matter is that some of the software we're talking about is just as memory safe as a new Rust rewrite because it doesn't do anything unsafe, but the rewrite could introduce other bugs and differences that could break things.

I would say I don't stand on the side of "rewrite nothing", but I'm more of a realist here, in that we absolutely cannot "rewrite everything" perfectly in a memory safe language, and we should first determine if a particular tool should be rewritten in a memory safe language by doing some analysis and testing on that tool.

Certainly, even though I know no Rust and am not an expert in memory safety, I would say that in the future we should try not to write totally new software in memory unsafe languages, but I'm not everyone so I can't make that rule and ensure it sticks.

[tptacek]

Your stance, that audited C code is "just as memory safe" as new Rust, is wildly outside of the mainstream of software security. You're entitled to your opinions, but you're unlikely to find many qualified people to dive into a debate as unproductive as that. Plenty of carefully audited C code has later been found to have terrible flaws, and likely will again in the future.

[ok_dad]

Well then I guess "mainstream of software security" needs to do a better marketing job to explain to dumb programmers like me why I should be using memory safe programming languages!

Seriously, I would love to see a succinct explanation for the "rewrite everything" philosophy, but it seems religiously dogmatic to me so far and has done the opposite of convince me to use Rust (or another memory-safe language).

On the other hand, the "statically typed language" community has done a great job of convincing me that I should be using statically typed programming languages by showing many examples of where typing would help me in my day to day work, and now I like using Go a lot and I avoid tons of issues I had with Python in the past.

[tptacek]

No, they don't. Not in this case, at least. They can just build better software, and it will get adopted. You're writing Go already, so I'm not sure why anyone would want to burn time in pointless debates about this stuff. Carry on! You're already doing it right.

[ok_dad]

I wanted to point you at this, which is example zero for why rewriting in "memory safe language number X" isn't always the best path: https://news.ycombinator.com/item?id=33171028

I'm definitely not debating that using better languages is better, but what I am saying is that some tools written in C have been effectively tested in the real-world by being on billions of machines and being used millions of times per day. I am not totally sure, but I think if there were major issues with the current NTP implementations we would probably have found them by now? Maybe not! But, in any case, rewrites need to be more carefully considered, planned, and executed than just some people I don't know writing a new NTP in Rust and stating it's fine to use for 80% of cases.

Thanks for having a nice discussion with me, I think I am a bit more convinced that we need to rewrite some stuff, but perhaps also more convinced that we need to do a better job of picking what to rewrite and why!

[tptacek]

Yes, I understand the point you're making that sufficiently audited C code is as safe as Rust. No, it isn't. Where that sufficiently-audited C code is feasible to replace, it will all be replaced. Browsers may take a decade or two, but C/C++-language NTP servers had better head for the bunkers and hope for some global cataclysm to halt all progress in the industry.

[tptacek]

Incidentally, I just happened across the thread you linked to (I didn't bother to follow the link before; it just isn't germane to the point I'm here to make).

Importing drama from a random thread into a Show HN is pretty rude, and you shouldn't do it again.

Not to me! I'm happy with the discussion here, and will participate as long as you keep providing opportunities to point out (read: preen about) other problems with memory-unsafe software.

But it's super rude to the person who submitted their code to "Show HN". The rules on "Show HN" aren't the same as the rules for the rest of the site, because people are vulnerable when you're sharing new work. This particular person wasn't submitting their "rm with trash" program as part of an argument against memory-unsafe software. For all we know, they just like Rust, which is a legitimate reason to write in Rust. Further, approximately nobody in the industry is worried about whether "rm" is implemented in C or Rust. Your dig had nothing to do with "rmt" and everything to do with wanting to score points on this thread.

You might consider apologizing to the "rmt" person.

[stoplying1]

The irony of you calling others dogmatic in this conversation is a cue for me to stop reading it, I guess.

[stoplying1]

What you're doing is just FUD bordering on some kind of weird concern trolling.

Gonna blow your mind when I tell you every single coreutil on my system is built with Rust and moreover nearly every program on my system was BUILT with that Rust-built coreutils.

Amazingly emulating some existing program behavior in Rust is easier than writing safe C! Who would've guessed? (besides eeveyone else watching and betting on Rust for the past 8 years)

[ok_dad]

See: https://news.ycombinator.com/item?id=33179880