It is regrettable that they're trying to coerce the use of Rust everywhere just for the sake of it. It's a nonsense that is now forced on everyone.
The comments gives a link to a recent talk about the motivation for using Rust in Git: <a href="https://github.com/bk2204/talk-rust-in-git/blob/dev/presentation.adoc#rust-in-git-status-internals-and-features" rel="nofollow">https://github.com/bk2204/talk-rust-in-git/blob/dev/presenta...
I wouldn't agree with all of those reasons, but it's very definitely not "just for the sake of it." One of the better reasons so many people look to writing some things in Rust is that we now have pretty ample evidence than trying to write a binary file format parser in C is a cornucopia of CVEs that are just simply absent in Rust, and the excuse of "well, but a sufficiently smart programmer doesn't write bugs in C" doesn't cut it anymore.
Somehow we have binary file format parsers written in C everywhere, so the real world shows it is possible and we do have programmers capable of doing it.
The issue isn't whether it's possible to have parsers, but whether it's possible to have them be secure, and periodic CVEs "everywhere" suggest we don't
Aside from memory safety, which is solved by using a compiler that just doesn't allow unsafe memory operations (so not GCC or Clang upstream), which CVEs specifically would have been ameliorated by a parser written in Rust instead of C?
coliveira · · focus · HN ↗
jcranmer · · focus · HN ↗
I wouldn't agree with all of those reasons, but it's very definitely not "just for the sake of it." One of the better reasons so many people look to writing some things in Rust is that we now have pretty ample evidence than trying to write a binary file format parser in C is a cornucopia of CVEs that are just simply absent in Rust, and the excuse of "well, but a sufficiently smart programmer doesn't write bugs in C" doesn't cut it anymore.
coliveira · · focus · HN ↗
eviks · · focus · HN ↗
cxr · · focus · HN ↗
eviks · · focus · HN ↗
cxr · · focus · HN ↗