On Fri, Jul 18, 2025 at 12:29:16AM +0000, brian m. carlson wrote: > 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]. I am also aligned with allowing Rust into Git. I think the ecosystem has kind of settled on Rust as the next system-level programming language, and it does have good interop with C. I think with the ongoing efforts to reduce our reliance on global state we should eventually be able to encapsulate more and more of our subsystems. And once they are neatly encapsulated we would be able to swap out their respective implementation and plug in a Rust replacement. Good candidates are for example the reftable library, as I've already proposed in the past. > > 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. Fully agreed. I've said so at the last contributors summit, but I think it would become awfully unmaintainable if we retain two implementations of every subsystem that we convert to Rust. If we decide to use Rust I would strongly advocate for going all-in. Patrick
