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

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

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

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

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

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

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

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

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