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.

▲

serbuvlad 11 minutes ago | parent | next [-]

fwiw, the use of C is infinitely more "coerced" than the use of Rust.

on my Linux system, C takes ownership of a 'top-level' /usr/include directory, all the kernel APIs have their canonical definitions in C headers, a lot of system features like nsswitch require dynamically linked C libraries etc. etc.

Rust is just something that programs can choose to be written in and that doesn't inconvenience me in any way.

▲

jcranmer 3 hours ago | parent | prev | next [-]

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.

▲

coliveira 3 hours ago | parent [-]

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.

▲

112233 2 hours ago | parent | next [-]

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?

▲

jcranmer 3 hours ago | parent | prev | next [-]

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.

▲

eviks 3 hours ago | parent | prev [-]

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

▲

cxr 3 hours ago | parent [-]

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?

▲

eviks an hour ago | parent | next [-]

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

▲

duskwuff 2 hours ago | parent | prev [-]

> 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).

▲

hellcow an hour ago | parent [-]

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

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

	▲	rpadovani 21 minutes ago \| parent [-]
		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.

▲

epidemian 3 hours ago | parent | prev | next [-]

Of the codebases i know that have adopted Rust, it has always been because some of their maintainers wanted to do so.

Maybe git's case is different though. Do you have more info about it? Are you a git maintainer who was coerced to use Rust, or do you know of such cases?

▲

tombert 4 hours ago | parent | prev [-]

I don't think it's "just for the sake of it". I think they believe that the Rust code will be safer.

▲

coliveira 4 hours ago | parent [-]

If that's the case, they should stop using git and Linux right now, because it's everything written in C. Having 0.1% of the code in a safe language will not change anything, it's only a bad security blanket.

	▲	aw1621107 3 hours ago \| parent \| next [-]
		> Having 0.1% of the code in a safe language will not change anything, it's only a bad security blanket. Just because something does provide an immediate perfect solution does not mean it isn't not worth investigating and/or pursuing. Also consider that bugs tend to be more prevalent in new code (e.g., [0]) as a result, you are likely to see more of a benefit from writing new code in a memory-safe language than raw line count proportions would indicate. [0]: https://security.googleblog.com/2024/09/eliminating-memory-s...
	▲	nvme0n1p1 3 hours ago \| parent \| prev \| next [-]
		You don't believe in slowly and iteratively improving a codebase over time? Should git stick with its weird mishmash of C and perl and shell scripts forever, for tradition's sake, performance and maintainability be damned?
	▲	baq 23 minutes ago \| parent \| prev [-]
		Rewriting it all in rust with bug for bug compatibility and byte identical outputs won’t cost more than $100k in tokens, but I don’t think this is an answer you’re looking for