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
Attachment:
signature.asc
Description: PGP signature
