Hacker News Reader

Comment by jcranmer | Hacker News Reader

The comments gives a link to a recent talk about the motivation for using Rust in Git: 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.

View on HN

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.

Sure, we can write a binary file format parser in C. We just can't figure out how to write one that isn't buggy and lets someone infect your computer if you give it sufficiently inventive garbage.

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?

> Aside from memory safety, which is solved by using a compiler that just doesn't allow unsafe memory operations

I don't see how that's possible without turning the language into something that isn't C, either by adding significant new functionality (e.g. fat pointers) or subtracting enough functionality that it's a much less capable language (e.g. disallowing dynamic memory allocation).

Behold: https://fil-c.org/

An important improvement over rust is that "Fil-C has no unsafe statement."

As everything, there are compromises and prices to pay.

In case of fil-c, it is about 1.5-4x slower performance, and a memory overhead.

So, let's not present it as a panacea to all problems: there could good reasons to use it, but it isn't a magic trick.

Rust is slower too, and git is IO bound anyway, and routinely calls bash.

Rust is not 1.5-4x slower at all. Git is not IO bound at all, it is not saturating your IO device, it just performs IO a lot.

Aside from the fact that it's not solved by using an alternative compiler, why would you put the core advantage aside?

What?

Somehow we also have memory safety bugs everywhere, too. So real world shows bugs in C code are possible. What even is your argument? Real men write asm?

Reply on news.ycombinator.com