Hi, On Tue, Jul 22, 2025 at 9:03 AM Sam James <sam@xxxxxxxxxx> wrote: First of all, thanks to all the Gentoo folks for chiming in and providing specifics about platforms and their state. > > I am far from a Rust expert, but I think that a more modern, memory-safe > > language will attract newer contributors who may have a fresher > > perspective on the project, and I think that's a good thing. > > Aren't they likely to contribute to gitoxide? There, they get a clean > slate without having to deal with the least-fun part (bidings). I'm sure some are. But clearly there are others where the draw is improving git itself because of its installed base; in fact, we need look no further than this exact series we are commenting on to find proof of that -- one such new contributor submitted patches to use Rust in git, and found a significant speedup while doing so. Further, there's considerable interest from existing git developers to use Rust in git as well; last year at the Git contributor summit, usage of Rust in git was not only one of the topics of discussion, it was the top voted topic (meaning, the topic that the greatest number of git contributors wanted to discuss). > > It is also not the Git project's responsibility to ensure that every > > platform is Rust-friendly. > > That's true, of course. And nobody is entitled to indefinie updates, but > on the other hand, there's still some implicit contract with users. I > really don't think git would have the adoption it does today if it had > adopted a Rust-like language in the same state Rust is now from the > start. > > (In exactly the same way, git doesn't gratuitously break compatibility > every release either. Can it? Yes, and git can change the platforms it > runs on, but it's something to be taken seriously.) This feels kind of close to a false dichotomy between breaking compatibility every release and indefinite update entitlements. There is certainly some middle ground: discussing reducing the breadth of platform support in order to gain other benefits, then gathering feedback, making a plan, and announcing the upcoming change, etc. And we're already pretty deep into it. Concerns about losing out on some platforms have repeatedly slowed us down from adopting Rust years ago. Yet, the desire for Rust adoption keeps coming up anyway; see the threads starting at * https://lore.kernel.org/git/ZZ77NQkSuiRxRDwt@nand.local/ * https://lore.kernel.org/git/Zu2D%2Fb1ZJbTlC1ml@nand.local/ * https://lore.kernel.org/git/20241128-pks-meson-v10-22-79a3fb0cb3a6@xxxxxx/ (search for "Rust") * https://lore.kernel.org/git/cover.1723242556.git.steadmon@xxxxxxxxxx/ The discussion has also been picked up and reported outside the Git mailing list, e.g. https://lwn.net/Articles/998115/. And so, in addition to the optional contrib/libgit-rs and contrib/libgit-sys Rust components that have already been merged into git, and a new build system added in part to make it easier to adopt Rust, we now have the first patch series that proposes a hard dependency on Rust. Further, I'd like to comment a bit on the support of our users from another angle. We're also responsible for security for our users, and feel Rust would help (see e.g. https://litchipi.github.io/infosec/2023/01/24/git-code-audit-viewed-as-rust-programmer.html and https://github.com/bk2204/git/commit/fbeb1180c7473635a964daed2da642c53487782d). We're responsible for performance of Git for our users, and feel Rust would help (see the email that started this thread, https://lore.kernel.org/git/CABPp-BFOmwV-xBtjvtenb6RFz9wx2VWVpTeho0k=D8wsCCVwqQ@xxxxxxxxxxxxxx/, and brian's notes about [CPU multi-]threading elsewhere in this email thread we are in). And there are other benefits from using Rust that we believe would benefit our users. Thus, it's not just a question of responsibility to our users, because such a responsibility pulls us in different directions regarding usage of Rust. So we need to figure out how to weigh the needs of our different users. For many of us, and forgive the geeky comparison, we'll probably weigh those needs with something more akin to an L2 norm (most good for the most users) rather than an L-infinity norm (maximal difference in usability for a single user), which probably isn't to your liking. Anyway, there's been lots of discussion already. We can certainly still discuss more about exactly how to announce, when to adopt Rust, whether we'll support an existing C-only version of git for a longer period of time than normal, and even whether to continue to delay adopting Rust for a little longer. But my personal guess is that attempting to stop adoption of Rust is unlikely to win at this point. > > Hopefully the platforms that we currently support but won't after this > > patch series have niche enough workloads that they do not need the > > absolute latest-and-greatest Git release at all times. > > I mention this in my other email, but it's not just about ancient > platforms. It's also about new ones, or ones where Rust supports them > poorly despite them being relevant. This feels like you're trying to push the decision for a given platform to be a dichotomy between latest-and-greatest-Git or no-version-of-Git-at-all, despite the fact that Taylor suggested an alternative and you even quoted him. Can you comment on that alternative? Why would using the last C-only version of Git[1] until gccrs bridges the gap be a problem for these platforms? Thanks, Elijah [1] Well, C-only other than optional Rust components like contrib/libgit-rs and contrib/libgit-sys that have already been released.
