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

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

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

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.

gccrs targeting Rust 1.49 will use libstd (the standard library) and
libcore (the library for freestanding implementations) from Rust 1.49
and that means it will only support those platforms that Rust 1.49 did.
For instance, Rust added support for Apache NuttX relatively recently.
Even if it has stellar support in GCC, it won't work with that version
of gccrs because the underlying libraries don't support any of those
platforms.  The only thing you can target that you couldn't before are
systems that use neither libstd nor libcore—which essentially means the
Linux kernel.  It's like using a glibc from 2009 and expecting to work
on RISC-V—it simply won't[0].

If you need support for new platforms, that requires a much _newer_
version of Rust.  Thus, to be able to use gccrs, porters need to use the
existing gcc codegen backend and get that code in immediately so that
when gccrs is out and supports Rust 1.91, the standard library will work
with those platforms.  The fastest way to getting platforms supported is
to port LLVM and then add them to upstream Rust that way.

I know there has been much complaint about the six-week lifespan of Rust
releases.  I myself dislike that.  But the situation is that LTS
releases require extensive amounts of work and nobody has stepped up to
do that or pay for it to be done.  Without dedicated staffing, it's not
going to happen.  That also means that individual projects decide what
versions of Rust they do and don't want to support.

We're already supporting the version in Debian stable for a year after
the new release comes out, so we're already far behind what everyone
else is doing.  For comparison, Rust 1.48 is in Debian 11, so we'd be
supporting an effectively five-year-old compiler instead of a
three-year-old compiler.

Requiring Rust 1.49 instead of Rust 1.63 makes it harder to use tools
like bindgen and cbindgen, which exist to automatically create types and
functions in one language in the other.  That, in turn, will hinder our
ability to effectively write code that crosses the boundary and
introduce hard-to-find bugs, since we'll have to do that work manually.
My experience is that these kinds of bugs tend to actually show up more
frequently on less common platforms, like big-endian systems, so we'll
be worsening the platform experience for those systems.

For context, when we ported a core service from C to Rust at work, we
used bindgen to generate C struct definitions, which made the process
much easier and avoided random crashes.  As a result, nobody noticed the
fact that we ported it incrementally over a couple of years.  If we
hadn't used bindgen, we probably would have had lots of random segfaults
due to failing to maintain compatibility between Rust and C definitions
of the same structures, which users would not have appreciated and would
not have helped our goal of making our software more reliable and easier
to maintain.

> The gccrs maintainers are actively working on that backend, and as far
> as I understand the main difference between LLVM and gccrs is that the
> latter doesn't have to be ported over to every single platform
> individually.

I don't think that's the case.  gccrs has to be compiled for every
platform just like LLVM does.  LLVM is actually easier to support
because it can cross-compile from any platform to any platform without
recompilation.  For instance, I can target riscv64gc-unknown-openbsd on
my Debian amd64 laptop assuming I can provide the necessary libraries
for OpenBSD when compiling, but GCC requires me to specifically compile
a compiler for that platform.

In any event, any portability changes will also likely need to go into
libstd and libcore, which is used identically with both compilers.

It is, however, the case that GCC supports more architectures (and
possibly more architecture/OS combinations) than LLVM.  For instance,
DEC Alpha and IA64 are only supported by GCC at the moment.

> 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.

I want to be clear I'm not opposed to supporting less common operating
systems or architectures.  For many years, my laptop was a PowerPC Mac,
and I've owned UltraSPARC, MIPS, and ARM hardware.  For personal code, I
try to test it in CI on at least Linux, macOS, FreeBSD, and NetBSD.  But
also, when a Debian package has not worked properly on PowerPC or
UltraSPARC, I've stepped up and fixed it.  My requests to other projects
when porting have been things like asking to write valid C or C++ (by
not making unaligned accesses or avoiding endianness assumptions, for
instance) and not to refrain from adding new languages or features.

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.

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.

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.

> 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.

[0] RISC-V was developed in 2010.
[1] https://www.reddit.com/r/rust/comments/lfysy9/pythons_cryptography_package_introduced_build/
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]