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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Sep 5, 2025, 19:34 UTC
Message-ID: <aLs7SwT-Gd6hXuvH@fruit.crustytoothpaste.net>
In-Reply-To: <11394b17-905a-4888-981c-c5b4a7f8cd62@gentoo.org>

On 2025-09-05 at 14:32:49, Eli Schwartz wrote:

Show 13 quoted lines

> 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.

Show 10 quoted lines

> 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