Subject: Re: [PATCH 0/7] RFC: Accelerate xdiff and begin its rustification

From: "brian m. carlson" <[email-masked]>
Date: Fri, 18 Jul 2025 00:29:16 +0000

On 2025-07-17 at 22:25:23, Taylor Blau wrote:
> I agree. I don't think that there is ever going to be a "perfect" time
> to introduce a hard dependency on Rust, and I don't think that should
> hold the project back from adopting it.
> 
> I am far from a Rust expert, but I think that a more modern, memory-safe
> language will attract newer contributors who may have a fresher
> perspective on the project, and I think that's a good thing.

Yes, I think that's true.  Rust is by far the most admired programming
language to work with, according to the 2024 Stack Overflow Developer
Survey.  We will likely attract new contributors who find C intimidating
or a bit of a hassle[0] but are excited about working on Rust,
especially in a project as compelling as Git[1].

> The alternative, of course, is to continue to use C and not take any
> dependency on Rust. I think there is a middle-ground in there somewhere
> to be able to build with (e.g.) "make" or "make RUST=1", but I would
> really like to see the project take a firmer stance here.
> 
> I worry that having build support for both "with Rust" and "C only" will
> create a headache not just at the build system level, but also in the
> code itself. Having a patchwork of features, optimizations, or bug fixes
> that either are or aren't supported depending on whether Rust support
> was specified at build-time seems like a worst-of-all-worlds outcome.

I definitely agree.  I already find it terribly inconvenient when I end
up when `git grep` doesn't support `-P` and I imagine that having lots
of features that weren't available would be bothersome.

I also think that using a combination of C and Rust will end up with us
still writing a lot of unsafe Rust code to interoperate with C.  If we
want to reap the benefits in terms of memory and thread safety[2], we'll
be better off sticking with just Rust.

I will also say that while it may be more challenging to compile Git at
first on Windows, as we move more towards an all-Rust codebase, Git may
end up being easier to maintain there as we depend more on the standard
library.

> Agreed. Of course, I think we would all like Git to be able to build and
> run on as many platforms as is reasonably possible. But we cannot
> support all platforms for all time. It is also not the Git project's
> responsibility to ensure that every platform is Rust-friendly.
> 
> Hopefully the platforms that we currently support but won't after this
> patch series have niche enough workloads that they do not need the
> absolute latest-and-greatest Git release at all times.

I will also point out that many OS and CPU architectures are actually
supported in Rust upstream.  `rustc --print target-list` includes things
like the following:

* m68k-unknown-linux-gnu (Amiga and other 68000 processors on Linux)
* wasm32-unknown-unknown (Git in your browser?)
* armv7a-nuttx-eabi (ARM processors running the embedded NuttX OS)
* x86_64-pc-cygwin (Cygwin[3])
* sparc64-unknown-openbsd (OpenBSD on UltraSPARC)

All Debian release architectures are supported, for instance, as well as
several non-release architectures.  The only Debian architectures that I
don't believe are supported are alpha, hppa, ia64, sh4, and x32 (which
is an amd64 variant that can run amd64 code just fine).

> Yeah, I think that this is the most interesting part of the discussion
> here. I am not knowledgeable enough about Rust's release cadence and
> platform compatibility to have an opinion here. But I trust brian's
> judgement ;-).

I'll see what Ezekiel thinks about this and I can send out a patch for
review if that's desired.

[0] I've been writing C for three-quarters of my life and I still find
debugging segfaults and other memory problems to be annoying and
tiresome, so I'm very interested in getting out of that business while
working on Git.  While the limiting factor for my contributions to Git
is often time, I would feel more excited about working on Git in Rust
than in C and I'm confident I'd write better quality code and more unit
tests as well (which benefits us and our users as well).
[1] I definitely think there's a cool factor to working on Git.
[2] Having more thread-safe code might allow us to more easily add
threading to other parts of Git that would benefit from it and thus
improve performance in many cases.
[3] This was missing for a long time, but it's finally here now, which
is also good news for Git for Windows.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA