Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

From: Patrick Steinhardt <ps@pks.im>
Date: Sep 22, 2025, 13:01 UTC
Message-ID: <aNFIjWKX2Wa6GEkA@pks.im>
In-Reply-To: <6674eb07df107d786b747ccd6dce4555d36d5d2c.camel@physik.fu-berlin.de>

On Fri, Sep 19, 2025 at 08:41:45PM +0200, John Paul Adrian Glaubitz wrote:

Show 30 quoted lines

> On Thu, 2025-09-04 at 16:26 +0200, Patrick Steinhardt wrote:
> > this small patch series introduces Rust into the core of Git. This patch
> > series is designed as a test balloon, similar to how we introduced test
> > balloons for C99 features in the past. The goal is threefold:
> > 
> >   - Give us some time to experiment with Rust and introduce proper build
> >     infrastructure.
> > 
> >   - Give distributors time to ease into the new toolchain requirements.
> >     Introducing Rust is impossible for some platforms and hard for
> >     others.
> > 
> >   - Announce that Git 3.0 will make Rust a mandatory part of our build
> >     infrastructure.
> 
> I'm one of Debian's maintainers in Debian Ports and I maintain Debian unstable
> on older and more obscure architectures such as alpha, hppa, m68k, sh4 and sparc64.
> 
> Of all the architectures in Debian, there are currently four architectures that
> don't support rustc. Those are alpha, hppa, m68k and sh4 [1]. For m68k, the
> situation is special as both LLVM and rustc already support m68k but with Linux
> still defaulting to 16-bit alignment on this architecture [2], building LLVM and
> rustc is currently not possible. I'm working on a switch to 32-bit alignment
> though which is default for NetBSD/m68k and also what specified in the official
> SysV ELF ABI documentation.
> 
> In general, I'm not against introducing Rust support into existing projects. However,
> I wished projects would be a little more patient until either the GCC codegen in
> rustc called rustc_codegen_gcc [3] or the Rust frontend in GCC have become ready
> for prime time.

Thanks for raising these concerns, I really appreciate that! Making platform maintainers aware of this upcoming change was one of the goals of announcing the breaking change in the first place, so I'm happy to see that this discussion is happening now :) After all, we are aware that the proposed change can create hardships for downstream distributions and maintainers.

The timeline I have layed out right now is trying to cater towards gccrs, at least to a certain extent. As Pierre-Emmanuel mentioned in [1], gccrs _may_ start to become ready next year with a target version of Rust 1.49. Given proposed timelines, Git 3.0 with mandatory Rust would be released at the end of next year, which would hopefully be after gccrs slowly becoming a viable alternative to compile Rust.

This is also the reason why I've picked Rust 2018 as the edition, as Rust 1.49 doesn't know about any later editions.

Of course, given that the work on gccrs is driven by volunteers to the best of my understanding I don't want to "force" them to get this done by that point, and Pierre-Emmanual also made clear that the initial release is still likely to have many bugs. So it may be the case that gccrs or any other codegen is not ready yet at that point in time. If so, we might have to reopen the discussion of whether or not we really want to switch over to mandatory Rust with Git 3.0.

Ultimately, I guess that this will also depend on how much of a pain it is for us to keep Rust non-mandatory. We don't have a lot of experience with Rust in our codebase yet, but if we eventually see that it's a breeze to keep it optional I think we should consider deferring the date where it's becoming mandatory.

All to say: I don't think we should blindly pull the trigger with Git 3.0. I think we should take a more nuanced approach and consider:

  - Any of the learnings we had with the initial Rust infra and how hard
    it is to keep it optional.

  - The status quo of the ecosystem and whether we can expect either
    gccrs or rustc_codegen_gcc to become stable.

That being said, I think we should keep the current intent spelt out in our breaking changes document so that we can get more feedback from downstream maintainers that aren't currently aware of the porposed upcoming change.

Thanks!

Patrick

[1]: <7bf054a1-0196-4ad8-aaa4-a432cd2c93a5@embecosm.com>