On Tue, Sep 02, 2025 at 05:27:10PM +0000, brian m. carlson wrote:
> On 2025-09-02 at 11:16:19, Patrick Steinhardt wrote:
> > As Pierre-Emmanuel menitoned in [1], the backend is likely to stabilize
> > next year. One or two years of backports for that particular LTS version
> > doesn't feel too bad. And if it does become more involved we can maybe
> > also distribute the load and rely on maintainers of impacted platforms
> > without Rust to help out with the backporting.
>
> I'm very much in favour of supporting gccrs when it's available, but I
> also want to say that it currently is targeting 1.49, which is much
> older than we want. It's also not necessarily going to be fully usable
> or bug free in that amount of time.
I cannot really say much about this. Overall I think that the rapid
release cycles and rapid adoption by projects that one typically sees in
Rust are an indicator to me that the whole ecosystem is not yet stable.
If I had the choice, I'd much rather adopt an ancient version of Rust if
it means that more platforms can support it.
> I also want to point out that it's important that the maintainers of
> affected platforms build the tooling necessary for their platforms to be
> supported. I'm not seeing ports of LLVM to those architectures or
> contributions to gccrs that would make those platforms easier to
> support.
The gccrs maintainers are actively working on that backend, and as far
as I understand the main difference between LLVM and gccrs is that the
latter doesn't have to be ported over to every single platform
individually.
> > Also, all of this feels like a significant shift. I'm strongly in favor
> > of adopting Rust in our codebase, but I think we should do so carefully.
> > So we might take it extra carefully and say that Rust will become a
> > mandatory dependency in Git 3.0, where the last release before Git 3.0
> > will become an LTS release.
>
> I'd prefer we not wait that long. I'm doing some work in building the
> new loose object mapping using Rust and it's much more efficient than
> writing it in C because we don't have to sort the data when we use a
> BTreeMap. The code is much simpler, shorter, and easier to write.
I still think we need to be mindful around the community though. I
understand that we want to have Rust in the codebase, and as I said I'm
in favor of adopting it. But we also have a certain responsibility with
Git given that it's used by almost every single developer out there.
A compromise could be to ease into Rust: we adopt Rust, but before Git
3.0 it is entirely optional. So Git will continue to work alright even
if there is no Rust compiler available. On the one hand this plays
nicely with platforms that do not have Rust. On the other hand it also
allows us to slowly iterate on the build infra for Rust, because I'm
very sure that there's going to be issues there initially.
With that we can:
- Build confidence in our Rust tooling.
- Figure out things as we go.
- Give distributions and other platforms enough time to prepare for
Rust becoming mandatory.
I think adopting Rust as a mandatory dependency out of nowhere would not
be playing nice. It may require significant effort from distros to adapt
to the new reality, so we should give them time to do so.
Note that I'm not saying that we need to have both a C and Rust
implementation for everything written in Rust. I don't think that's
sustainable in any way. But any feature written in Rust should be a
_new_ feature that can be disabled and that users can live without for
the time being.
> Nobody else is currently working on the interoperability code and we
> expressed that we ideally wanted it for Git 3.0. Being able to use Rust
> means I can write that code faster, with fewer errors (and hence less
> debugging time), and better tests. Otherwise, I'm afraid that it will
> take longer and we might not have it fully upstream for Git 3.0.
>
> We also have this series right now, which we'd have to abandon if we're
> not going to support Rust right away. I'd like to retain Ezekiel as a
> contributor and incorporate Rust, and I think the best time to adopt
> Rust is now, not at Git 3.0.
It would be a shame, but right now it's a risky bet to build anything on
top of Rust given that we don't officially accept it in Git yet. We need
to first make the decision whether or not we want to have it right now,
and if so how that's supposed to look like.
Patrick
