On 2025-08-23 at 18:30:26, Elijah Newren wrote: > I don't think that's fair. A quick reminder on the history: There was > lots of excitement about potentially introducing Rust two years ago at > our virtual Git contributors conference. Taylor formally proposed > adopting it on the mailing list a year and a half ago. And at Git > Merge last year, among those in attendance, there was broad > significant interest in adopting Rust with unanimous support for > letting it move forward among those that were present (which, yes, we > know wasn't everyone). And there's the three rounds so far of this > patch series. At every discussion where you weren't present, someone > else would always bring up you and NonStop, and point out how you've > been a very positive long-term member of the Git community and how > Rust adoption would likely negatively affect you, which would be > regrettable. We waited years to adopt Rust precisely (and I believe > solely) because of your objections. Josh and Calvin even went the > route of making optional not-even-built-by-default Rust libraries > (libgit-rs and libgit-sys) when they wanted to add some Rust bindings. > If years of deference by other community members isn't considered > taking you seriously, I don't know what is. > > I agree that it is disappointing that there isn't a clear way to both > gain the compelling advantages of Rust while also retaining the full > current extent of our widespread platform support. It's doubly > unfortunate since you're such a positive contributing member of the > community. But not allowing us to ever gain the advantages of Rust is > problematic too. So, a decision has to be made, one way or the other. I think it's worth saying that I do appreciate your (Randall's) positive contributions as well and I would love some way to continue to support NonStop as we adopt Rust. To be clear, I care deeply about portability: I have owned PowerPC, UltraSPARC, MIPS, and ARM hardware, and I test many of my personal projects on at least Linux, FreeBSD, and NetBSD. There is an alternative Rust compiler, mrustc[0], which is written in C++ and that I have played around with to see if it could meet our needs. I've been very busy lately and haven't had the time to test it out fully, and although it will likely require some upstream changes for static libraries and a compatibility wrapper because its minicargo is very limited in functionality, it might be an option that we could leverage. There will necessarily be work on Rust upstream as well, but I'm hoping that mrustc will at least open doors for us. I also think that Rust is becoming a more and more common language in technology because of its interoperability with C and its memory safety. The support policy I wrote up explains why there is an increasing push from governments, security professionals, and the technology industry for memory-safe languages. If Git is to continue its success and broad adoption, we don't want it to be labelled software that is using security anti-patterns, and we also don't want it to be a CVE factory like libxml2 or ImageMagick. This is the reason I ultimately started work on the SHA-256 project many years ago: I knew we'd need to do it for security reasons and that without a more secure hash algorithm, Git would eventually be dropped. My hope is that NonStop can find some way to support Rust because I think it's a compelling language and NonStop would greatly benefit from the wider variety of software available. My sense of previous discussions was that we do very much want NonStop to continue to come along as we support Rust in Git and that if there are ways we make it easier for both, we'd want to do that. That's certainly my view, at least. [0] https://github.com/thepowersgang/mrustc -- brian m. carlson (they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
