Patrick Steinhardt <ps@xxxxxx> writes: > On Thu, Sep 04, 2025 at 12:57:25AM +0000, brian m. carlson wrote: >> On 2025-09-03 at 05:40:54, Patrick Steinhardt wrote: >> > 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 think you may be assuming that gccrs targeting Rust 1.49 will >> magically make it work on more platforms than upstream Rust will. >> That's not the case. > > I don't have enough context to be able to tell. I'm mostly going by what > the gccrs maintainers themselves are saying. But if I'm misunderstanding > what gccrs will bring to the table I'm happy to be corrected. > (I also think it's obvious that once gccrs can handle 1.49, we will have to put effort into making things build with it. Not sure who wanted or claimed magic. I just think relyling on a single implementation isn't a good idea.) > [snip] >> > 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. >> >> We've actually had this discussion on the list several times where we've >> proposed the inclusion of Rust. This is not the first time it's come >> up, or the second. It was explicitly mentioned a year ago on the list >> that we wanted to adopt Rust in the notes from the Contributor Summit. >> >> There has been plenty of notice that this is coming down the line. It's >> not accurate to claim it's "out of nowhere" nor to claim that people >> have not had plenty of time to port their systems. >> >> Distros and porters should not be insensible to the increasing use of >> Rust or the need for them to get their systems working. For instance, >> you cannot run a GNOME or MATE desktop environment without librsvg2, >> which is written in Rust. Python's cryptography package adopted Rust >> over four years ago and there was the same gnashing of teeth[1], yet >> little progress has been made by porters on the same affected >> architectures since that time. In that time, Debian has bootstrapped >> and released an entire RISC-V port, complete with Rust. > > Discussions of theoretical nature are one thing though. The transition > that is actually happening is a different thing, and distributions will > need to prepare for this. We already had multiple distro maintainers > coming into these discussions saying that this will require a bunch of > work, which should be an indicator to us that we need to take it slow. > We should accommodate for that. I imagine most distributions have absolutely zero awareness of this thread or plans for git. See below. > > [snip] >> It should be stated that there is a very easy way to get Rust working, >> and that's to port LLVM to the platform in question. IA-64 was removed >> in 2009, but it might be possible to resurrect that out of tree if >> there's interest and maybe even get it re-accepted upstream. I'll point >> out that AIX, Solaris, and QNX have done the necessary porting work to >> get LLVM and Rust working over the past couple years, so it's not out of >> the question for other platforms to do so as well. And, for the >> avoidance of doubt, I would be absolutely delighted if we were able to >> support additional platforms with Rust as well. > > I cannot really say how hard or easy it is to port LLVM to a different > platform. I'd be surprised though if that work really was that easy. I think it's an interesting characterisation indeed. > >> Also, the approach of making it an optional component directly >> contradicts the proposed policy I wrote up. That's a recipe for >> additional burdensome work maintaining two implementations, when we >> actually want to make it easier for people to contribute functionality. >> It also doesn't provide any of the memory safety benefits or address any >> of the concerns from governments, security professionals, and other >> parties about the real and substantial risks of continuing to develop in >> C. > > The only reason why we want to have it as an optional component is to > make the transitioning period easier for downstream distributors. And > the intent is not to convert major components -- it should be trivial > components that we can use as test balloons, similar to how we did it > for all of our C99 test balloons. Yes, even if it were just for one release, having it optional for something would mean we can adjust packaging without some huge pressure where git had 0 Rust in one release and then mandatory Rust in another. (I would of course prefer far more than one release, but I've tried throughout this thread to give options even if the one I'd prefer isn't pursued, not "teeth gnash"). sam
