On 9/5/25 8:45 AM, Matthias Aßhauer wrote: > > > On Fri, 5 Sep 2025, Patrick Steinhardt wrote: > >> Over the last couple of years the appetite for bringin Rust into the >> codebase has grown significantly across the developer base. Introducing >> Rust is a major change though and has ramifications for the whole >> ecosystem: >> >> - Some platforms haven't yet been able to implement a Rust toolchain, >> even though it is possible in theory. >> >> - Some platforms don't have any support for Rust at all. > > What's the difference between these two kinds of platform? It should be > theoretically possible to build rust tooling for all of them, right? 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. 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). >> +The Git project will declare the last version before Git 3.0 to be a >> long-term >> +support release that is maintained until alternate Rust backends like >> gcc-rs are >> +able to build Git. The Git project may need to rely on distributions >> to help > > 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. 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 Maybe it will be the great subversion renaissance. ... At any rate I do not expect GCC-rs to be abandoned, huge effort has been put into it, many people are interested, they have funding to work on it, and projects such as the Linux kernel want to see it exist because they depend on GCC for their C code, want to have Rust code, and the kernel security mitigations depend in part on being able to use the same bytecode format for all code, to enable LTO and CFI visibility across languages. It is quite *unreasonable* to assume that interest will fade. No more than to assume that *Git*s interest in Rust will fade. The chances of it being *abandoned* without https://github.com/rust-lang/rust itself supporting at least all interesting Linux Kernel architectures including use of GCC as an alternative codegen backend, are... very low, in my opinion. Obviously, lacking the ability to prophesize the future, no one can know if it will "takes an unexpectedly long time". Although again, significant interest and all that. Not sure that would be my biggest worry. They seem to be making reasonably effective use of their time projections so far, though I will be happy to take correction if someone knows something I've missed... -- Eli Schwartz
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
