Re: [PATCH v3 02/15] xdiff: introduce rust

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 3926 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]