Subject: Re: [PATCH RFC v2 5/7] BreakingChanges: announce Rust becoming mandatory

From: "brian m. carlson" <[email-masked]>
Date: Fri, 5 Sep 2025 19:34:35 +0000

On 2025-09-05 at 14:32:49, Eli Schwartz wrote:
> LLVM is theoretically an open source project. So is Rust. We can ask
> people on those platforms how successful they have been at the political
> side of convincing the Rust project to allowlist the platforms inside
> low-level case statements of platform-specific defines, in order to
> attempt the first round of "try running make, see what breaks and start
> fixing it".
> 
> Hint: it did not go well, in the sense that the rust maintainers even
> accepted the validity of making a proposal in the first place.
> 
> LLVM is easier to work with, at least in that sense. But not all
> platforms are supported by LLVM either, and you do need a stable release
> of LLVM to support the platform before you can begin work on rust at all.

It is possible to build with a custom LLVM because all of the
distributions do it, so it is possible to build the work out of tree and
then add it when everything is ready.  I mentioned elsewhere in the
discussions that LLVM upstream said that work on IA-64 could continue
out of tree and then it could be re-added if there was sufficient
maintenance and support, so this is at least in theory a viable option.

If LLVM and Rust upstreams are just completely unreasonable and won't
accept certain platforms at all (which I doubt), then distros can carry
patches.  It's not pretty and it's a bunch of hassle, but it's common.

I'll also say that LLVM is a pretty useful piece of software that most
distros will want to have.  It provides clangd, which is one of the the
major C and C++ LSPs; it's used by Doxygen, which is a major
documentation generator; and it's used by Mesa and PostgreSQL, which are
pieces of software people will want to use.  And, as well, it provides a
complete compiler toolchain.  So I think there are compelling reasons
why porting LLVM is valuable functionality to have anyway, in addition
to the fact that it also gets you most of the way towards Rust (and a
variety of other, less common languages).

> That is the advantage of GCC-rs -- it has much broader platform support,
> so if the rust frontend works at all, it will likely also work on the
> specific platform you care about (and the GCC developers usually don't
> bite, even if you want to enable experimental support for new platforms).

I agree gccrs is a great project and of course I want it to succeed.
Clearly having multiple independent implementations makes it easier to
find bugs and increases portability.  And if it means that we get better
platform support, fantastic.

However, if your complaint is that Rust upstream will not allow
platform-specific defines and other incremental work without support in
LLVM or other core toolchain components, then I don't see how gccrs is
going to convince them otherwise.  I also pointed out elsewhere that the
compiler is but one part of the equation and that libstd and libcore,
which are shared between the implementations, plus their dependencies,
are absolutely required for Rust to work on any platform.  If Rust
upstream doesn't allow support for the standard libraries, then distros
will have to carry patches, gccrs or not.

To be clear, I do support this kind of incremental work since it's a
valuable way to do large projects (and it's what I did for SHA-256 in
Git and am doing for SHA-1/SHA-256 interop), but saying, "brian and
other Git contributors say this is a good idea" may not be more
convincing.  To the extent I can encourage this kind of thing, I am
happy to do so, though.

> > Do we want to commit to promising support until gccrs is ready? What if
> > gccrs ends up abandoned? Or takes an unexpectedly long time to reach a
> > stage where it can build Git? It might make sense to give this LTS
> > release a time limit instead, or in addidtion.

I think a two-year limit is reasonable.  As anyone who speaks Spanish
will tell you, there's a degree of uncertainty when speculating about
the future, so we cannot guarantee that gccrs, however promising it
might currently appear, will be usable or viable in that time.  We
cannot agree to backport patches forever if gccrs doesn't materialize,
so a time limit seems like a good idea.

_However_, I will state that I am interested in seeing if we can get
mrustc to build Git's Rust code.  I understand that it is not intended
to do that (it's intended primarily to bootstrap Rust) and it definitely
will require some patches to get working, but I think it's at least a
possibility and it seems like a much lower effort way to solve the
problem.  It will probably involve some inconvenience on our part
because it's very limited in its toolchain and fake cargo, but I would
be willing to deal with said inconvenience for the purposes of
portability.  And it works now and is (for its limited purpose) actively
maintained.

> Well, that will one way or another mean users of such platforms cannot
> use git at all, not even old versions, lest they be hacked. Bit of a
> problem for an application that mainly exists for the purpose of
> communicating over the network. I suppose such platforms can finally
> leave the world of DVCSes, given:
> 
> - jj, breezy, and mercurial all use rust already
> - bitkeeper and monotone are dead
> - darcs is written in GHC (haskell) which is far less available than
>   rust

There are other Git-compatible options.  There's Game of Trees, which
uses Git repositories and is being designed by OpenBSD.  It isn't
drop-in compatible, since it's designed to meet the OpenBSD team's
needs, but it appears to be basically functional (and is shipped in
Debian, no less).

There's also libgit2 and Dulwich, which also implement Git repositories.

So there are options for people who want to use Git on platforms that
don't support Rust.  I suspect that the lack of Git on certain platforms
will actually be more of a problem for those platforms than for Git,
though.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA