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. [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. [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. > 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. We cannot just pull the rug away under their feet without advance notice that this is going to happen. > For example, there is zero chance I will implement any of the > SHA-1/SHA-256 compatibility code twice. I'm already doing that in my > free time without any compensation at all and it's unreasonable to > expect me to do it twice or even to #ifdef out all the places it would > need to go. I am happy to let someone else take responsibility for the > project instead, however, if they would like to do those things. And that's totally fair. From my point of view, this compatibility code is a _new_ feature that we are adding to Git. And as I mentioned, I think it is reasonable to say that new features may be implemented in Rust now already, as platforms that aren't yet ready wouldn't lose any existing functionality. > > 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. > > I think we had made the decision at the 2024 Contributor's Summit that > we wanted to adopt Rust in Git, so it was more of a matter of sending > the patches than actually making that decision. As I recall, the > decision was unanimous. I think most or even all of the contributors are on board. But we never really talked about timelines, or how we want to introduce Rust, so that's a discussion we need to have now. Patrick
