Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Sergey Fedorov]

This will be a disaster, please consider not making rust mandatory.
It will break git for all systems without rust, in effect killing not only possibility to use GitHub and other git-based services, but also breaking build systems, since many ports – and package managers – rely on git to fetch sources.
As for local version control, git could be replaced with some alternative (likely inferior, but at least that is not the end).
There is no replacement, AFAIK, for build systems and for git-based online services.

P. S. In case anyone wonders, this is personally relevant for me: I won’t be able to continue contributing to open-source anymore (at least certainly not like in past years) with git being unusable due to broken rust.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Ezekiel Newren]

On Fri, Sep 19, 2025 at 11:36 AM Sergey Fedorov
<barracuda@macos-powerpc.org> wrote:
> This will be a disaster, please consider not making rust mandatory.
> It will break git for all systems without rust, in effect killing not only possibility to use GitHub and other git-based services, but also breaking build systems, since many ports – and package managers – rely on git to fetch sources.
> As for local version control, git could be replaced with some alternative (likely inferior, but at least that is not the end).
> There is no replacement, AFAIK, for build systems and for git-based online services.
>
> P. S. In case anyone wonders, this is personally relevant for me: I won’t be able to continue contributing to open-source anymore (at least certainly not like in past years) with git being unusable due to broken rust.

The mailing list has had extremely heated debates about this, and
there are many who would agree and disagree with you. So please try to
read my comment as a genuine interest in trying to understand your
situation. I would like to hear why making Rust mandatory would make
using and contributing to Git insurmountable. We know for sure that
NonStop currently does not support Rust at all, and that there are
problems with porting Rust to Gentoo, but I'd like to hear what OSes
and Architectures you use personally and professionally and why adding
Rust would be a bad idea. Is it corporate policy? Is it that the Rust
toolchain doesn't exist for your os/arch? Is it that Rust is a new
language and isn't as battle tested as C? Something else?

I believe that even "I don't know Rust and don't want to learn it."
would be a valid comment to add as well. I think the discussion of
Rust has been so hot because we (the Git community) don't understand
everyone's situations and how they'll be affected, and what could
possibly be done to address concerns.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Collin Funk]

Ezekiel Newren <ezekielnewren@gmail.com> writes:

> On Fri, Sep 19, 2025 at 11:36 AM Sergey Fedorov
> <barracuda@macos-powerpc.org> wrote:
>> This will be a disaster, please consider not making rust mandatory.
>> It will break git for all systems without rust, in effect killing not only possibility to use GitHub and other git-based services, but also breaking build systems, since many ports – and package managers – rely on git to fetch sources.
>> As for local version control, git could be replaced with some alternative (likely inferior, but at least that is not the end).
>> There is no replacement, AFAIK, for build systems and for git-based online services.
>>
>> P. S. In case anyone wonders, this is personally relevant for me: I won’t be able to continue contributing to open-source anymore (at least certainly not like in past years) with git being unusable due to broken rust.
>
> The mailing list has had extremely heated debates about this, and
> there are many who would agree and disagree with you. So please try to
> read my comment as a genuine interest in trying to understand your
> situation. I would like to hear why making Rust mandatory would make
> using and contributing to Git insurmountable. We know for sure that
> NonStop currently does not support Rust at all, and that there are
> problems with porting Rust to Gentoo, but I'd like to hear what OSes
> and Architectures you use personally and professionally and why adding
> Rust would be a bad idea. Is it corporate policy? Is it that the Rust
> toolchain doesn't exist for your os/arch? Is it that Rust is a new
> language and isn't as battle tested as C? Something else?
>
> I believe that even "I don't know Rust and don't want to learn it."
> would be a valid comment to add as well. I think the discussion of
> Rust has been so hot because we (the Git community) don't understand
> everyone's situations and how they'll be affected, and what could
> possibly be done to address concerns.

Based on the domain of their email they use MacOS PowerPC. AFAIK LLVM
has not supported it for a long time.

Collin

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Florian Märkl]

> Ezekiel Newren <ezekielnewren@gmail.com> wrote:
> 
> I'd like to hear what OSes
> and Architectures you use personally and professionally and why adding
> Rust would be a bad idea.

To add some specific cases from my side as well, problematic platforms include
Mac OS X on ppc as well as OpenBSD/macppc (32-bit). Both of these are still
relevant, as OpenBSD is actively maintained on this architecture and Mac OS X
10.5 is supported by MacPorts, resulting in a system with modern tools that is
still able to run and debug certain legacy software.

In particular, in the Rizin project, we use both platforms regularly to test
our code for architecture and OS-specific bugs, and we also support them to run
Rizin itself for debugging and analyzing software there.

I do not advocate not adopting Rust because of the language itself, but I think
it is important to compare the maturity of the compiler and ecosystem to the
project that will strictly depend on it.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Michael Orlitzky]

> We know for sure that NonStop currently does not support Rust at
> all, and that there are problems with porting Rust to Gentoo, but
> I'd like to hear what OSes and Architectures you use personally and
> professionally and why adding Rust would be a bad idea. Is it
> corporate policy? Is it that the Rust toolchain doesn't exist for
> your os/arch? Is it that Rust is a new language and isn't as battle
> tested as C? Something else?

There is no problem with supporting rust on Gentoo. Gentoo users build
from source, and rust is a problem for anyone who builds from
source. I'm writing this on a riscv/musl system. If there are no
binaries for your CPU/libc, let me tell you, it's not fun. And this is
like, my job. A normal person would be completely helpless.

Nevertheless, the arch support issues are secondary. I'm sure it's a
lot of fun for the people who are writing rust code to do cargo
updates in the two or three directories they work in all day. But I'm
not writing rust code, don't care what language git is written in, and
have hundreds of other packages to keep up-to-date on multiple
machines. I want to be able to use my package manager to do that
efficiently. You know, the main tangible benefit of using a linux
distribution.

But every distribution is "packaging" rust the same way. They're
bundling random old versions of crates in violation of their own
policies because the ecosystem is unstable and the tooling encourages
tight coupling. By requiring rust, you are require me to go back to
managing dependencies like I'm on Windows XP again. Git is the most
important program I use, but it's not more important than package
management itself.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Sam James]

Michael Orlitzky <michael@orlitzky.com> writes:

>> We know for sure that NonStop currently does not support Rust at
>> all, and that there are problems with porting Rust to Gentoo, but
>> I'd like to hear what OSes and Architectures you use personally and
>> professionally and why adding Rust would be a bad idea. Is it
>> corporate policy? Is it that the Rust toolchain doesn't exist for
>> your os/arch? Is it that Rust is a new language and isn't as battle
>> tested as C? Something else?
>
> There is no problem with supporting rust on Gentoo. Gentoo users build
> from source, and rust is a problem for anyone who builds from
> source. I'm writing this on a riscv/musl system. If there are no
> binaries for your CPU/libc, let me tell you, it's not fun. And this is
> like, my job. A normal person would be completely helpless.
>

That is precisely the problem that Eli and I have been describing in
this thread (along with some more minor issues for Prefix to figure out,
and then missing arch support where Rust doesn't support it at all).

He is referencing issues we brought up earlier in the (various) threads,
not plucking it out of thin air.

> Nevertheless, the arch support issues are secondary. I'm sure it's a
> lot of fun for the people who are writing rust code to do cargo
> updates in the two or three directories they work in all day. But I'm
> not writing rust code, don't care what language git is written in, and
> have hundreds of other packages to keep up-to-date on multiple
> machines. I want to be able to use my package manager to do that
> efficiently. You know, the main tangible benefit of using a linux
> distribution.
>
> But every distribution is "packaging" rust the same way. They're
> bundling random old versions of crates in violation of their own
> policies because the ecosystem is unstable and the tooling encourages
> tight coupling. By requiring rust, you are require me to go back to
> managing dependencies like I'm on Windows XP again. Git is the most
> important program I use, but it's not more important than package
> management itself.

Indeed, this is all terrible, and I agree with you, of course.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[brian m. carlson]

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

On 2025-09-22 at 15:59:49, Michael Orlitzky wrote:
> There is no problem with supporting rust on Gentoo. Gentoo users build
> from source, and rust is a problem for anyone who builds from
> source. I'm writing this on a riscv/musl system. If there are no
> binaries for your CPU/libc, let me tell you, it's not fun. And this is
> like, my job. A normal person would be completely helpless.

This is a problem with languages that bootstrap from earlier versions of
themselves.  It also happens with other, less common languages.  GHC (a
Haskell runtime) also has this problem and any distro that ships pandoc
has to deal with it.

It is certainly inconvenient, but there is mrustc to help the bootstrap
process.  Granted, it does not work everywhere yet, but it should also
not be too difficult to make it do so.

I do think the difficulty is worth it, though.  With Rust, we're going
to get code that is thread-safe and memory-safe by the virtue of the
fact that it compiles and that will allow us to have threading in more
parts of the code where it might benefit us.  I also cannot tell you how
many segfaults and null pointer dereferences I've written in Git (some
in the past week) that are just no longer possible with Rust.

As my proposal originally mentioned, there is enormous pressure from
governments, security professionals, and large companies to improve
memory safety, which I believe are legitimate concerns.  If we want Git
to continue to be used widely, then we need to address those issues and
Rust seems to be the best possible way to do that.  I don't think
continuing in C only is going to be viable long term.

> Nevertheless, the arch support issues are secondary. I'm sure it's a
> lot of fun for the people who are writing rust code to do cargo
> updates in the two or three directories they work in all day. But I'm
> not writing rust code, don't care what language git is written in, and
> have hundreds of other packages to keep up-to-date on multiple
> machines. I want to be able to use my package manager to do that
> efficiently. You know, the main tangible benefit of using a linux
> distribution.

I don't think this is going to happen as you anticipate it will.  My
original policy was to target Debian stable's release for a year after
the new Debian stable came out and that will make using many crates
nearly impossible.  We are going to have to be _extremely_ careful about
dependencies in general and the things we are likely to use are things
like bindgen and cbindgen, where typically an old version will work just
fine and which are already packaged in major distros.  We are not going
to be adding dependencies willy-nilly and running `cargo update` every
other day.

> But every distribution is "packaging" rust the same way. They're
> bundling random old versions of crates in violation of their own
> policies because the ecosystem is unstable and the tooling encourages
> tight coupling. By requiring rust, you are require me to go back to
> managing dependencies like I'm on Windows XP again. Git is the most
> important program I use, but it's not more important than package
> management itself.

I expect Debian already packages the crates that we need in acceptable
versions, and I assume other distros do as well, so I don't anticipate
this being a problem for us.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

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

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Sam James]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> On 2025-09-22 at 15:59:49, Michael Orlitzky wrote:
>> There is no problem with supporting rust on Gentoo. Gentoo users build
>> from source, and rust is a problem for anyone who builds from
>> source. I'm writing this on a riscv/musl system. If there are no
>> binaries for your CPU/libc, let me tell you, it's not fun. And this is
>> like, my job. A normal person would be completely helpless.
>
> This is a problem with languages that bootstrap from earlier versions of
> themselves.  It also happens with other, less common languages.  GHC (a
> Haskell runtime) also has this problem and any distro that ships pandoc
> has to deal with it.

Usually there's nothing too critical in such a language ;)

>
> It is certainly inconvenient, but there is mrustc to help the bootstrap
> process.  Granted, it does not work everywhere yet, but it should also
> not be too difficult to make it do so.
>
> I do think the difficulty is worth it, though.  With Rust, we're going
> to get code that is thread-safe and memory-safe by the virtue of the
> fact that it compiles and that will allow us to have threading in more
> parts of the code where it might benefit us.  I also cannot tell you how
> many segfaults and null pointer dereferences I've written in Git (some
> in the past week) that are just no longer possible with Rust.
>
> As my proposal originally mentioned, there is enormous pressure from
> governments, security professionals, and large companies to improve
> memory safety, which I believe are legitimate concerns.  If we want Git
> to continue to be used widely, then we need to address those issues and
> Rust seems to be the best possible way to do that.  I don't think
> continuing in C only is going to be viable long term.
>
>> Nevertheless, the arch support issues are secondary. I'm sure it's a
>> lot of fun for the people who are writing rust code to do cargo
>> updates in the two or three directories they work in all day. But I'm
>> not writing rust code, don't care what language git is written in, and
>> have hundreds of other packages to keep up-to-date on multiple
>> machines. I want to be able to use my package manager to do that
>> efficiently. You know, the main tangible benefit of using a linux
>> distribution.
>
> I don't think this is going to happen as you anticipate it will.  My
> original policy was to target Debian stable's release for a year after
> the new Debian stable came out and that will make using many crates
> nearly impossible.  We are going to have to be _extremely_ careful about
> dependencies in general and the things we are likely to use are things
> like bindgen and cbindgen, where typically an old version will work just
> fine and which are already packaged in major distros.  We are not going
> to be adding dependencies willy-nilly and running `cargo update` every
> other day.

That brings me significant comfort and I'm glad to hear it. I hope
others agree with your position on having significant restraint on the
use of external crates.

git has always been quite good about dependencies pre-Rust.

>
>> But every distribution is "packaging" rust the same way. They're
>> bundling random old versions of crates in violation of their own
>> policies because the ecosystem is unstable and the tooling encourages
>> tight coupling. By requiring rust, you are require me to go back to
>> managing dependencies like I'm on Windows XP again. Git is the most
>> important program I use, but it's not more important than package
>> management itself.
>
> I expect Debian already packages the crates that we need in acceptable
> versions, and I assume other distros do as well, so I don't anticipate
> this being a problem for us.

Yes, I expect on our end in Gentoo, that we'll probably need to use this
to finally migrate to a Debian-style handling of crates, though that's
not your problem.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Patrick Steinhardt]

On Mon, Sep 22, 2025 at 10:47:03PM +0100, Sam James wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> > I don't think this is going to happen as you anticipate it will.  My
> > original policy was to target Debian stable's release for a year after
> > the new Debian stable came out and that will make using many crates
> > nearly impossible.  We are going to have to be _extremely_ careful about
> > dependencies in general and the things we are likely to use are things
> > like bindgen and cbindgen, where typically an old version will work just
> > fine and which are already packaged in major distros.  We are not going
> > to be adding dependencies willy-nilly and running `cargo update` every
> > other day.
> 
> That brings me significant comfort and I'm glad to hear it. I hope
> others agree with your position on having significant restraint on the
> use of external crates.
> 
> git has always been quite good about dependencies pre-Rust.

I certainly echo brian's sentiment here. Rust dependencies are easy to
use, but they are also one part that worries me quite significantly due
to multiple reasons:

  - Pulling in many dependencies opens us up for supply chain attacks.

  - Every single dependency is a source for vulnerabilities in general.
    We're already good enough in creating these ourselves.

  - Dependencies may have hard requirements on the Rust version,
    requiring us to bump the minimum required toolchain version.

  - In general, I'm not a fan of having even dozens of dependencies. It
    causes bloat and externalizes a bunch of knowledge.

So I think we should and need to be very conservative about adding any
new dependencies. There will be cases where it makes sense, but every
new dependency should be well-reasoned.

After this patch series lands, one of the next steps will also be to add
a policy for how we want to use Rust in the Git project. brian has
already written such a policy (see e.g. [1]), and it already mentions
that we'll need to be careful about adding dependencies. Might be worth
it to flesh that part out a bit more, but that's something we can
discuss at a later point.

Patrick

[1]: <6d065f550fe871cf010409f7bd2a63438cf52723.1756496539.git.gitgitgadget@gmail.com>

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Michael Orlitzky]

On Mon, 2025-09-22 at 21:35 +0000, brian m. carlson wrote:
> On 2025-09-22 at 15:59:49, Michael Orlitzky wrote:
> > There is no problem with supporting rust on Gentoo. Gentoo users build
> > from source, and rust is a problem for anyone who builds from
> > source. I'm writing this on a riscv/musl system. If there are no
> > binaries for your CPU/libc, let me tell you, it's not fun. And this is
> > like, my job. A normal person would be completely helpless.
> 
> This is a problem with languages that bootstrap from earlier versions of
> themselves.  It also happens with other, less common languages.  GHC (a
> Haskell runtime) also has this problem and any distro that ships pandoc
> has to deal with it.

Spectacular example.

In Gentoo we support the following arches: alpha, amd64, arm, arm64,
hppa, loong, m68k, mips, ppc, ppc64, riscv, s390, sparc, and x86. We
support both glibc and musl, for 23 arch/libc combinations (we don't
support musl on every arch).

Pandoc supports: amd64, arm64, ppc64, riscv and x86, but only on glibc.
That's 5 out of 23. If you're able to use GHC 9.2 released in 2021,
that is. Otherwise it's 0 out of 23. No one "has to deal with"
anything.

Coincidentally, I am one of only a few people to bootstrap a modern GHC
on riscv/musl:

  https://wiki.gentoo.org/wiki/User:Mjo/GHC_binary_packages

Knowing the amount of work involved, I can promise that if Git switched
to Haskell today, it would be our users who would have to deal with...
not having Git any more.

I agree completely when it comes to the benefits of static typing and
memory safety. (I've been writing Haskell for 15 years, after all.) But
for the time being, all of the cures are worse than the disease.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Sergey Fedorov]

> but I'd like to hear what OSes and Architectures you use personally and professionally and why adding Rust would be a bad idea.

I am the maintainer of ports for Darwin on PowerPC systems (few past years in MacPorts and now in https://github.com/macos-powerpc/powerpc-ports fork) and contributor to GCC (gfortran). I have added the whole of current R ecosystem into MacPorts and a decent support for modern Fortran via FPM.

Those systems are still actively used, and thanks to GCC upstream support of powerpc-apple-darwin I have been able to keep our ports pretty much on par (occasionally ahead of) what modern macOS has at the moment. A lot of work has been done in past two-three years, including fixing/restoring support for ppc for several major langs/compilers (gfortran, MLton, SBCL, Ruby, OCaml, Idris2 etc.), build systems etc.

Git is essential for the version control, but also for the build systems of MacPorts and CMake. Since my powerpc ports rely on MacPorts infrastructure (there are 40k+ ports), I need a working Git for my workflow.

To be clear, I do not object to adding Rust optionally (as I would not against adding optional modules for any language), but making it mandatory, while Rust is still broken on a few, admittedly edge case, systems, hurts the open-source.

I agree with John Paul Adrian that once gccrs becomes properly usable, or otherwise gcc codegen in Rust acquires support for currently unsupported platforms, things will change.

P. S. I have contributed to mrustc, so it is not ideological. Though I do think that ability to bootstrap from source is strictly required for a compiler to be safe, and at the moment bootstrapping of Rust may not yet work for all supported platforms (at least it is not well-tested).

References:
https://github.com/rust-lang/rfcs/issues/1312
https://github.com/thepowersgang/mrustc/issues/300

Regards,
Sergey Fedorov
macos-powerpc.org

RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[rsbecker]

On September 20, 2025 4:30 Am, Sergey Fedorov wrote:
>> but I'd like to hear what OSes and Architectures you use personally and
>professionally and why adding Rust would be a bad idea.
>
>I am the maintainer of ports for Darwin on PowerPC systems (few past years
in
>MacPorts and now in https://github.com/macos-powerpc/powerpc-ports fork)
>and contributor to GCC (gfortran). I have added the whole of current R
ecosystem
>into MacPorts and a decent support for modern Fortran via FPM.
>
>Those systems are still actively used, and thanks to GCC upstream support
of
>powerpc-apple-darwin I have been able to keep our ports pretty much on par
>(occasionally ahead of) what modern macOS has at the moment. A lot of work
has
>been done in past two-three years, including fixing/restoring support for
ppc for
>several major langs/compilers (gfortran, MLton, SBCL, Ruby, OCaml, Idris2
etc.),
>build systems etc.
>
>Git is essential for the version control, but also for the build systems of
MacPorts
>and CMake. Since my powerpc ports rely on MacPorts infrastructure (there
are
>40k+ ports), I need a working Git for my workflow.
>
>To be clear, I do not object to adding Rust optionally (as I would not
against adding
>optional modules for any language), but making it mandatory, while Rust is
still
>broken on a few, admittedly edge case, systems, hurts the open-source.
>
>I agree with John Paul Adrian that once gccrs becomes properly usable, or
otherwise
>gcc codegen in Rust acquires support for currently unsupported platforms,
things
>will change.
>
>P. S. I have contributed to mrustc, so it is not ideological. Though I do
think that
>ability to bootstrap from source is strictly required for a compiler to be
safe, and at
>the moment bootstrapping of Rust may not yet work for all supported
platforms (at
>least it is not well-tested).
>
>References:
>https://github.com/rust-lang/rfcs/issues/1312
>https://github.com/thepowersgang/mrustc/issues/300

To clarify, gcc is not available on all platforms. The overlap where gcc is
supported
and Rust is support is likely high, but more, where gcc is not supported
then it is
highly unlikely that Rust is supported. mrustc is a difficult more that
requires gcc
even if that is not clearly stated - it does not build with c17, for
example. This
double requirement is making the probability of being able to continue to
support
git even less for me on NonStop. My team is working hard to push Rust
availability
and we realize that gccrs is an easier path, but those two are currently
outside
of our control because of complexities in the loader on NonStop.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Ezekiel Newren]

On Sat, Sep 20, 2025 at 12:39 PM <rsbecker@nexbridge.com> wrote:
> To clarify, gcc is not available on all platforms. The overlap where gcc is
> supported and Rust is support is likely high, but more, where gcc is not
> supported then it is highly unlikely that Rust is supported. mrustc is a
> difficult more that requires gcc even if that is not clearly stated - it
> does not build with c17, for example. This double requirement is making the
> probability of being able to continue to support git even less for me on
> NonStop. My team is working hard to push Rust availability and we realize
> that gccrs is an easier path, but those two are currently outside of our
> control because of complexities in the loader on NonStop.

Is there a C compiler that works on NonStop and Linux? I ask because
I'm wondering if code from gccrs could help with augmenting that
compiler. From what I understand gccrs is written in C++17, but Rust's
native approach uses mrustc to bootstrap, and then the rest of the
Rust compiler is written in Rust. I don't have $500,000 to spare for
testing on real NonStop hardware, but if there was a C compiler that
worked on NonStop and Linux then there'd at least be the possibility
of people trying to make Rust work with it.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Sam James]

Ezekiel Newren <ezekielnewren@gmail.com> writes:

> On Sat, Sep 20, 2025 at 12:39 PM <rsbecker@nexbridge.com> wrote:
>> To clarify, gcc is not available on all platforms. The overlap where gcc is
>> supported and Rust is support is likely high, but more, where gcc is not
>> supported then it is highly unlikely that Rust is supported. mrustc is a
>> difficult more that requires gcc even if that is not clearly stated - it
>> does not build with c17, for example. This double requirement is making the
>> probability of being able to continue to support git even less for me on
>> NonStop. My team is working hard to push Rust availability and we realize
>> that gccrs is an easier path, but those two are currently outside of our
>> control because of complexities in the loader on NonStop.
>
> Is there a C compiler that works on NonStop and Linux? I ask because
> I'm wondering if code from gccrs could help with augmenting that
> compiler. From what I understand gccrs is written in C++17, but Rust's
> native approach uses mrustc to bootstrap, and then the rest of the
> Rust compiler is written in Rust. I don't have $500,000 to spare for
> testing on real NonStop hardware, but if there was a C compiler that
> worked on NonStop and Linux then there'd at least be the possibility
> of people trying to make Rust work with it.

[Just some small technical notes, it doesn't need a reply.]

GCC defaults to C++17 but is written in C++14 (recently changed from
C++11). I think the gccrs people may have talked about whether they can
use C++17 to make some things easier (I suspect if they requested that,
it would be approved, at least I'd support it and argue in favour).

mrustc isn't part of any official Rust bootstrap path, Rust upstream
just use binaries. mrustc currently needs GCC for some trivial reasons
(like hardcoding some workarounds for bugs w/ GCC-specific flags). I
suspect it wouldn't be too hard to get it working with Clang. I don't
know how many extensions it relies on in general that may be common but
not in the standard.

But mrustc is written in C++, not C -- AFAIK NonStop has no C++ compiler.

RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[rsbecker]

On September 20, 2025 3:01 PM, Ezekiel Newren wrote:
>On Sat, Sep 20, 2025 at 12:39 PM <rsbecker@nexbridge.com> wrote:
>> To clarify, gcc is not available on all platforms. The overlap where
>> gcc is supported and Rust is support is likely high, but more, where
>> gcc is not supported then it is highly unlikely that Rust is
>> supported. mrustc is a difficult more that requires gcc even if that
>> is not clearly stated - it does not build with c17, for example. This
>> double requirement is making the probability of being able to continue
>> to support git even less for me on NonStop. My team is working hard to
>> push Rust availability and we realize that gccrs is an easier path,
>> but those two are currently outside of our control because of complexities in the
>loader on NonStop.
>
>Is there a C compiler that works on NonStop and Linux? I ask because I'm
>wondering if code from gccrs could help with augmenting that compiler. From what
>I understand gccrs is written in C++17, but Rust's native approach uses mrustc to
>bootstrap, and then the rest of the Rust compiler is written in Rust. I don't have
>$500,000 to spare for testing on real NonStop hardware, but if there was a C
>compiler that worked on NonStop and Linux then there'd at least be the possibility
>of people trying to make Rust work with it.

All I have is a C++17 compiler. gcc -std=c17 might work for compatibility on Linux but none
of the gcc extensions work.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Ezekiel Newren]

On Sat, Sep 20, 2025 at 5:18 PM <rsbecker@nexbridge.com> wrote:
> All I have is a C++17 compiler. gcc -std=c17 might work for compatibility on Linux but none
> of the gcc extensions work.

What I meant was: Is there a compiler that can be compiled to both
NonStop and Linux. What is the name of the C++17 compiler that you use
on NonStop? Is there a Linux or Windows cross compiler that can target
NonStop?

RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[rsbecker]

On September 20, 2025 7:48 PM, Ezekiel Newren wrote:
>On Sat, Sep 20, 2025 at 5:18 PM <rsbecker@nexbridge.com> wrote:
>> All I have is a C++17 compiler. gcc -std=c17 might work for
>> compatibility on Linux but none of the gcc extensions work.
>
>What I meant was: Is there a compiler that can be compiled to both NonStop and
>Linux. What is the name of the C++17 compiler that you use on NonStop? Is there a
>Linux or Windows cross compiler that can target NonStop?

We have c99, c11, c17. The only Windows cross compiler is c99, but that requires
a license from HPE that I cannot provide. There are not non-commercial compilers
available that can be used to cross compile. Also, standard configure processing
does not work on Windows for NonStop.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Ezekiel Newren]

On Sat, Sep 20, 2025 at 7:15 PM <rsbecker@nexbridge.com> wrote:
> >What I meant was: Is there a compiler that can be compiled to both NonStop and
> >Linux. What is the name of the C++17 compiler that you use on NonStop? Is there a
> >Linux or Windows cross compiler that can target NonStop?
>
> We have c99, c11, c17. The only Windows cross compiler is c99, but that requires
> a license from HPE that I cannot provide. There are not non-commercial compilers
> available that can be used to cross compile. Also, standard configure processing
> does not work on Windows for NonStop.

If C/C++ can be cross compiled from Windows to a NonStop target, then
why does Git need to run on NonStop itself? Why couldn't you use Git
on Windows and then copy the compiled executables to your NonStop
targets?

RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[rsbecker]

On September 20, 2025 9:24 PM, Ezekiel Newren wrote:
>On Sat, Sep 20, 2025 at 7:15 PM <rsbecker@nexbridge.com> wrote:
>> >What I meant was: Is there a compiler that can be compiled to both
>> >NonStop and Linux. What is the name of the C++17 compiler that you
>> >use on NonStop? Is there a Linux or Windows cross compiler that can target
>NonStop?
>>
>> We have c99, c11, c17. The only Windows cross compiler is c99, but
>> that requires a license from HPE that I cannot provide. There are not
>> non-commercial compilers available that can be used to cross compile.
>> Also, standard configure processing does not work on Windows for NonStop.
>
>If C/C++ can be cross compiled from Windows to a NonStop target, then why does
>Git need to run on NonStop itself? Why couldn't you use Git on Windows and then
>copy the compiled executables to your NonStop targets?

This is a much longer discussion. Windows is simply not a trusted platform. NonStop
is. Building on NonStop provides a virus free/malware free container that passes audit
requirements for financial transactions that cannot be demonstrated on Windows. I
have customers who refuse all attempts at building anything on NonStop.

In addition, production control cannot be done from windows. There is more to
life than Dev in DevSecOps, which is the only thing Windows builds gives you. Unless
git runs on NonStop, production artifacts (scripts, configuration, deployed objects)
cannot be audited and controlled.

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Ezekiel Newren]

On Sat, Sep 20, 2025 at 9:18 PM <rsbecker@nexbridge.com> wrote:
> This is a much longer discussion. Windows is simply not a trusted platform. NonStop
> is. Building on NonStop provides a virus free/malware free container that passes audit
> requirements for financial transactions that cannot be demonstrated on Windows. I
> have customers who refuse all attempts at building anything on NonStop.
>
> In addition, production control cannot be done from windows. There is more to
> life than Dev in DevSecOps, which is the only thing Windows builds gives you. Unless
> git runs on NonStop, production artifacts (scripts, configuration, deployed objects)
> cannot be audited and controlled.

Can linux cross compile to NonStop? If so, would Linux be able to pass
audit requirements?

It seems like this might be a first mover problem. HPE NonStop doesn't
want to support Rust because no one is demanding it from them, but
engineers don't ask for it (or rather, aren't heard) because HPE
NonStop refuses to support it. I'll bet NonStop doesn't support Git
because why would they pay for it when you're doing it for them for
free. and now people are talking about adding Rust to Git which means
Git won't work on NonStop and then something breaks and management
screams at you to "fix it", but you can't because their policy forbade
you from using the tools that would allow you to "fix it".

Am I telling the story right?

RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[rsbecker]

On September 21, 2025 12:49 PM, Ezekiel Newren wrote:
>On Sat, Sep 20, 2025 at 9:18 PM <rsbecker@nexbridge.com> wrote:
>> This is a much longer discussion. Windows is simply not a trusted
>> platform. NonStop is. Building on NonStop provides a virus
>> free/malware free container that passes audit requirements for
>> financial transactions that cannot be demonstrated on Windows. I have
>customers who refuse all attempts at building anything on NonStop.
>>
>> In addition, production control cannot be done from windows. There is
>> more to life than Dev in DevSecOps, which is the only thing Windows
>> builds gives you. Unless git runs on NonStop, production artifacts
>> (scripts, configuration, deployed objects) cannot be audited and controlled.
>
>Can linux cross compile to NonStop? If so, would Linux be able to pass audit
>requirements?
>
>It seems like this might be a first mover problem. HPE NonStop doesn't want to
>support Rust because no one is demanding it from them, but engineers don't ask
>for it (or rather, aren't heard) because HPE NonStop refuses to support it. I'll bet
>NonStop doesn't support Git because why would they pay for it when you're doing
>it for them for free. and now people are talking about adding Rust to Git which
>means Git won't work on NonStop and then something breaks and management
>screams at you to "fix it", but you can't because their policy forbade you from using
>the tools that would allow you to "fix it".
>
>Am I telling the story right?

Not really no. There is momentum for Rust on NonStop. It just takes time to get
budget for the effort. After getting budget, it takes time for the port. I am likely to
have some involvement in that, one way or another. NonStop does support git,
mostly through my ongoing efforts and they do use it extensively. This really is a
crucial application and the NonStop team does understand the implications. The
problem is that everything takes time, more than git is allowing in this case. I cannot
disclose more than that.

Yes, people are screaming at me to fix it, which is not easy. The policy is not the
Problem, but the technical limitations are. It is not a surprise, because I was involved
In the POSIX effort when it was first introduced on NonStop, not that many "in the know"
Listened to my concerns, which are now having significant consequences.

I am still working all possible angles to see that git stays relevant, and appreciate
any and all help from any source.

Randall "The Reluctant Prophet" Becker

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Ezekiel Newren]

On Sun, Sep 21, 2025 at 5:07 PM <rsbecker@nexbridge.com> wrote:
> Not really no. There is momentum for Rust on NonStop. It just takes time to get
> budget for the effort. After getting budget, it takes time for the port. I am likely to
> have some involvement in that, one way or another. NonStop does support git,
> mostly through my ongoing efforts and they do use it extensively. This really is a
> crucial application and the NonStop team does understand the implications. The
> problem is that everything takes time, more than git is allowing in this case. I cannot
> disclose more than that.

Ah, thank you for correcting me.

> Yes, people are screaming at me to fix it, which is not easy. The policy is not the
> Problem, but the technical limitations are. It is not a surprise, because I was involved
> In the POSIX effort when it was first introduced on NonStop, not that many "in the know"
> Listened to my concerns, which are now having significant consequences.

I think you've mentioned threading as a major technical hurdle for
Rust and GCC somewhere else on the mailing list (correct me if I'm
wrong). That's why I've worked very hard on single threaded only
translations. Also, I've been targeting Rust version 1.63.0 because
that's what debian requires and so my local Rust development is locked
to that version. I've managed to translate a huge amount of xdiff to
Rust using no Cargo dependencies. I figure if I keep my Rust adoption
effort as bare bones as possible that'll make it easier for NonStop to
catch up to Git's Rust bare minimum requirement. I have been talking
about adding cbindgen which pulls in like 40+ dependencies, but that's
a different case because its only purpose is to generate C header
files from parsed Rust files. I can write my Rust in a way that
cbindgen can be disabled and the generated header files can be checked
into Git or acquired somewhere else.

I have 2 questions for you.
What parts of Rust do you think will be easy to port?
What parts of Rust do you think will be difficult to port?

RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[rsbecker]

On September 21, 2025 7:42 PM, Ezekiel Newren wrote:
>On Sun, Sep 21, 2025 at 5:07 PM <rsbecker@nexbridge.com> wrote:
>> Not really no. There is momentum for Rust on NonStop. It just takes
>> time to get budget for the effort. After getting budget, it takes time
>> for the port. I am likely to have some involvement in that, one way or
>> another. NonStop does support git, mostly through my ongoing efforts
>> and they do use it extensively. This really is a crucial application
>> and the NonStop team does understand the implications. The problem is
>> that everything takes time, more than git is allowing in this case. I cannot disclose
>more than that.
>
>Ah, thank you for correcting me.
>
>> Yes, people are screaming at me to fix it, which is not easy. The
>> policy is not the Problem, but the technical limitations are. It is
>> not a surprise, because I was involved In the POSIX effort when it was first
>introduced on NonStop, not that many "in the know"
>> Listened to my concerns, which are now having significant consequences.
>
>I think you've mentioned threading as a major technical hurdle for Rust and GCC
>somewhere else on the mailing list (correct me if I'm wrong). That's why I've worked
>very hard on single threaded only translations. Also, I've been targeting Rust version
>1.63.0 because that's what debian requires and so my local Rust development is
>locked to that version. I've managed to translate a huge amount of xdiff to Rust
>using no Cargo dependencies. I figure if I keep my Rust adoption effort as bare
>bones as possible that'll make it easier for NonStop to catch up to Git's Rust bare
>minimum requirement. I have been talking about adding cbindgen which pulls in like
>40+ dependencies, but that's a different case because its only purpose is to generate
>C header files from parsed Rust files. I can write my Rust in a way that cbindgen can
>be disabled and the generated header files can be checked into Git or acquired
>somewhere else.
>
>I have 2 questions for you.
>What parts of Rust do you think will be easy to port?
>What parts of Rust do you think will be difficult to port?

I will ask the team member who are doing this port for their opinion.

Easy: NonStop is POSIX and has C17, so anything compatible with that should
not be difficult.
Hard: Anything that depends on assumptions that gcc works 100% on the
platform are hard and have to be worked around, so porting mrustc is considered
hard on that basis. Our first attempt at porting that did not go well as we have to
reconstruct the build options, at the very least, from scratch, while not strictly
difficult, it is always time consuming to figure out the intention.

[PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Patrick Steinhardt]

Hi,

this small patch series introduces Rust into the core of Git. This patch
series is designed as a test balloon, similar to how we introduced test
balloons for C99 features in the past. The goal is threefold:

  - Give us some time to experiment with Rust and introduce proper build
    infrastructure.

  - Give distributors time to ease into the new toolchain requirements.
    Introducing Rust is impossible for some platforms and hard for
    others.

  - Announce that Git 3.0 will make Rust a mandatory part of our build
    infrastructure.

The test balloon itself is quite uninteresting: I've chosen to convert
the "varint.c" subsystem, mostly because it is trivial and does not have
any dependencies. But it does allow us to verify that C to Rust interop
works as expected, and to play around with tooling. All tests pass with
the "varint.rs" implementation.

For now, the series only contains support for Meson. If we agree to go
down this route I'll also introduce support for Rust into our Makefiles
at a later point in time.

Furthermore missing is additional tooling:

  - At least one CI job to verify that Rust builds and works as
    expected.

  - Tooling and CI jobs to ensure that we have consistent formatting via
    `cargo format`.

And probably lots more. As said, the entire goal is for us to have an
easy playground that we can experiment on and develop the infrastructure
incrementally without yet having to commit to anything.

I'm mostly splitting out the topic of introducing Rust from the larger
series that introduce it into xdiff so that we can focus more on the
actual process of introducing Rust into Git and less on the potential
features that we want to build on top of it.

Thanks!

Patrick

---
Patrick Steinhardt (3):
      meson: add infrastructure to build internal Rust library
      rust: implement a test balloon via the "varint" subsystem
      BreakingChanges: announce Rust becoming mandatory

 Documentation/BreakingChanges.adoc | 20 +++++++++
 meson.build                        | 21 ++++++++-
 meson_options.txt                  |  2 +
 src/lib.rs                         |  1 +
 src/meson.build                    | 13 ++++++
 src/varint.rs                      | 92 ++++++++++++++++++++++++++++++++++++++
 6 files changed, 147 insertions(+), 2 deletions(-)


---
base-commit: 2462961280690837670d997bde64bd4ebf8ae66d
change-id: 20250904-b4-pks-rust-breaking-change-7167d9d3e37d

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[John Paul Adrian Glaubitz]

Hello Patrick,

On Thu, 2025-09-04 at 16:26 +0200, Patrick Steinhardt wrote:
> this small patch series introduces Rust into the core of Git. This patch
> series is designed as a test balloon, similar to how we introduced test
> balloons for C99 features in the past. The goal is threefold:
> 
>   - Give us some time to experiment with Rust and introduce proper build
>     infrastructure.
> 
>   - Give distributors time to ease into the new toolchain requirements.
>     Introducing Rust is impossible for some platforms and hard for
>     others.
> 
>   - Announce that Git 3.0 will make Rust a mandatory part of our build
>     infrastructure.

I'm one of Debian's maintainers in Debian Ports and I maintain Debian unstable
on older and more obscure architectures such as alpha, hppa, m68k, sh4 and sparc64.

Of all the architectures in Debian, there are currently four architectures that
don't support rustc. Those are alpha, hppa, m68k and sh4 [1]. For m68k, the
situation is special as both LLVM and rustc already support m68k but with Linux
still defaulting to 16-bit alignment on this architecture [2], building LLVM and
rustc is currently not possible. I'm working on a switch to 32-bit alignment
though which is default for NetBSD/m68k and also what specified in the official
SysV ELF ABI documentation.

In general, I'm not against introducing Rust support into existing projects. However,
I wished projects would be a little more patient until either the GCC codegen in
rustc called rustc_codegen_gcc [3] or the Rust frontend in GCC have become ready
for prime time.

My hope would be that more talented Rust developers would help support the two
GCC Rust projects so that these become ready for prime time sooner and that one
of the last blockers for introducing the Rust language across a lot of open source
projects would go away.

I'm not an expert with the Non-Stop operating system, but I could imagine that
a working Rust frontend in GCC would ease porting the Rust language to that
platform as well.

Cheers,
Adrian

> [1] https://buildd.debian.org/status/package.php?p=rustc&suite=sid
> [2] https://wiki.debian.org/M68k/Alignment
> [3] https://rust-for-linux.com/rustc_codegen_gcc
> [4] https://rust-for-linux.com/gccrs

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

[Patrick Steinhardt]

On Fri, Sep 19, 2025 at 08:41:45PM +0200, John Paul Adrian Glaubitz wrote:
> On Thu, 2025-09-04 at 16:26 +0200, Patrick Steinhardt wrote:
> > this small patch series introduces Rust into the core of Git. This patch
> > series is designed as a test balloon, similar to how we introduced test
> > balloons for C99 features in the past. The goal is threefold:
> > 
> >   - Give us some time to experiment with Rust and introduce proper build
> >     infrastructure.
> > 
> >   - Give distributors time to ease into the new toolchain requirements.
> >     Introducing Rust is impossible for some platforms and hard for
> >     others.
> > 
> >   - Announce that Git 3.0 will make Rust a mandatory part of our build
> >     infrastructure.
> 
> I'm one of Debian's maintainers in Debian Ports and I maintain Debian unstable
> on older and more obscure architectures such as alpha, hppa, m68k, sh4 and sparc64.
> 
> Of all the architectures in Debian, there are currently four architectures that
> don't support rustc. Those are alpha, hppa, m68k and sh4 [1]. For m68k, the
> situation is special as both LLVM and rustc already support m68k but with Linux
> still defaulting to 16-bit alignment on this architecture [2], building LLVM and
> rustc is currently not possible. I'm working on a switch to 32-bit alignment
> though which is default for NetBSD/m68k and also what specified in the official
> SysV ELF ABI documentation.
> 
> In general, I'm not against introducing Rust support into existing projects. However,
> I wished projects would be a little more patient until either the GCC codegen in
> rustc called rustc_codegen_gcc [3] or the Rust frontend in GCC have become ready
> for prime time.

Thanks for raising these concerns, I really appreciate that! Making
platform maintainers aware of this upcoming change was one of the goals
of announcing the breaking change in the first place, so I'm happy to
see that this discussion is happening now :) After all, we are aware
that the proposed change can create hardships for downstream
distributions and maintainers.

The timeline I have layed out right now is trying to cater towards
gccrs, at least to a certain extent. As Pierre-Emmanuel mentioned in
[1], gccrs _may_ start to become ready next year with a target version
of Rust 1.49. Given proposed timelines, Git 3.0 with mandatory Rust
would be released at the end of next year, which would hopefully be
after gccrs slowly becoming a viable alternative to compile Rust.

This is also the reason why I've picked Rust 2018 as the edition, as
Rust 1.49 doesn't know about any later editions.

Of course, given that the work on gccrs is driven by volunteers to the
best of my understanding I don't want to "force" them to get this done
by that point, and Pierre-Emmanual also made clear that the initial
release is still likely to have many bugs. So it may be the case that
gccrs or any other codegen is not ready yet at that point in time. If
so, we might have to reopen the discussion of whether or not we really
want to switch over to mandatory Rust with Git 3.0.

Ultimately, I guess that this will also depend on how much of a pain it
is for us to keep Rust non-mandatory. We don't have a lot of experience
with Rust in our codebase yet, but if we eventually see that it's a
breeze to keep it optional I think we should consider deferring the date
where it's becoming mandatory.

All to say: I don't think we should blindly pull the trigger with Git
3.0. I think we should take a more nuanced approach and consider:

  - Any of the learnings we had with the initial Rust infra and how hard
    it is to keep it optional.

  - The status quo of the ecosystem and whether we can expect either
    gccrs or rustc_codegen_gcc to become stable.

That being said, I think we should keep the current intent spelt out in
our breaking changes document so that we can get more feedback from
downstream maintainers that aren't currently aware of the porposed
upcoming change.

Thanks!

Patrick

[1]: <7bf054a1-0196-4ad8-aaa4-a432cd2c93a5@embecosm.com>