[ok_dad]

> the point you're making that sufficiently audited C code is as safe as Rust

The point I am actually trying to make is that memory safety is not the only consideration for security and safety. If you make a memory safe NTP and there turns out to be bad logic inside that code that does something allowing a security hole, then that's just as bad, if not worse, than using the decades-old software that did not have that bad logic, because that software has been tested in the real world day in day out for DECADES.

I trust (somewhat) that Rust isn't going to allow unsafe memory access. I don't trust that Rust programmers can write code with no bugs that's better than a tool that has been refined over generations of programmers. Memory safe programming is a tech solution to a human problem (human imperfection).

Again, new projects should be written in a memory safe language, but that's a whole other topic, IMO.

[tptacek]

The claim isn't that memory-safe languages foreclose on all security vulnerabilities; only the worst of them. As someone who has at various times had the job of carefully reviewing large C codebases for vulnerabilities, I'll attest: whatever the rest of the vulnerabilities may be, you spend most of your time trying (and failing) to hunt down all the memory corruption problems. Your confidence in the decades of review C programs have had, in all but a very few cases, is probably misplaced.

[ok_dad]

I’m not even saying reviews, I’m saying that code has been tested in “the arena” and been proven billions of times.

I used to work in incoming quality inspection, I know human reviews are at best 85 percent accurate. I’m arguing that decades of hammering on those old as hell programs have done the reviews for you.

[tptacek]

I've spent most of my career, which started around 1995, as a security researcher. I think you'd be surprised by how poor a job "the arena" does at sussing out complicated memory lifecycle problems in C and C++ code. Some of the patterns we now look for to find exploitable conditions aren't even all that old; much of that "arena time" was spent not even looking for those problems. Security teams at places like Google subject C/C++ code to fuzzing at boggling scales, and people still find memory safety vulnerabilities. Shit's hard. It's better just not to have this problem in the first place.

I'm not stamping my feet demanding you track down a Rust web browser. But the thread started with someone asking what the point of a Rust NTP daemon was. I think that's been amply answered now.

[stoplying1]

Ah and here it is. You're just very, very blatantly taking your biases from writing C and applying them to Rust. Do you just... Not believe every single blog post where people say "it was a bit harder to write, but it basically does what you want once you get it to compile"?

Are you just ignoring the NVME kernel driver dev who said literally the same thing about a quick naive implementation that is nearly as performant without optimization as the one that has been in tree and tuned for years?

This insistence on naysaying and defending a categorically indefensible language is baffling to me. How many major companies and products have to move to Rust and adopt it? Do y'all really convince yourselves that everyone is just in some hype train? Is this what it's like to not being able to inspect a technology and disambiguate hype from something real?