# Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty 13 messages from 2025-09-20 to 2025-09-22. Participants: Sergey Fedorov, rsbecker@nexbridge.com, Ezekiel Newren, Sam James. Thread: https://gitlist.dev/t/64174 ## Sergey Fedorov, 2025-09-20 08:29 Subject: Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty Message-ID: <8799E6DB-FC85-4F71-A6C1-363D1AC8ED06@macos-powerpc.org> URL: https://gitlist.dev/e/8799E6DB-FC85-4F71-A6C1-363D1AC8ED06%40macos-powerpc.org ``` > 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 ``` ## rsbecker@nexbridge.com, 2025-09-20 18:39 Subject: RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty Message-ID: <000001dc2a5d$ea10ffe0$be32ffa0$@nexbridge.com> URL: https://gitlist.dev/e/000001dc2a5d%24ea10ffe0%24be32ffa0%24%40nexbridge.com In-Reply-To: <8799E6DB-FC85-4F71-A6C1-363D1AC8ED06@macos-powerpc.org> ``` 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. ``` ## Ezekiel Newren, 2025-09-20 19:00 Subject: Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty Message-ID: URL: https://gitlist.dev/e/CAH%3DZcbDJR7gJ0tyQ-bk-n%2BZid_csED74%2BX5OkTfbEiy5-_2R-w%40mail.gmail.com In-Reply-To: <000001dc2a5d$ea10ffe0$be32ffa0$@nexbridge.com> ``` On Sat, Sep 20, 2025 at 12:39 PM 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. ``` ## Sam James, 2025-09-20 19:25 Subject: Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty Message-ID: <87qzw10vv9.fsf@gentoo.org> URL: https://gitlist.dev/e/87qzw10vv9.fsf%40gentoo.org In-Reply-To: ``` Ezekiel Newren writes: > On Sat, Sep 20, 2025 at 12:39 PM 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. ``` ## rsbecker@nexbridge.com, 2025-09-20 23:17 Subject: RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty Message-ID: <002001dc2a84$cda40380$68ec0a80$@nexbridge.com> URL: https://gitlist.dev/e/002001dc2a84%24cda40380%2468ec0a80%24%40nexbridge.com In-Reply-To: ``` On September 20, 2025 3:01 PM, Ezekiel Newren wrote: >On Sat, Sep 20, 2025 at 12:39 PM 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. ``` ## Ezekiel Newren, 2025-09-20 23:48 Subject: Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty Message-ID: URL: https://gitlist.dev/e/CAH%3DZcbCf4sWKhOcCe4UkX3Y9VXZ-iHeh4QZ3ExrX1hbn5GE3vA%40mail.gmail.com In-Reply-To: <002001dc2a84$cda40380$68ec0a80$@nexbridge.com> ``` On Sat, Sep 20, 2025 at 5:18 PM 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? ``` ## rsbecker@nexbridge.com, 2025-09-21 01:15 Subject: RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty Message-ID: <002c01dc2a95$400315f0$c00941d0$@nexbridge.com> URL: https://gitlist.dev/e/002c01dc2a95%24400315f0%24c00941d0%24%40nexbridge.com In-Reply-To: ``` On September 20, 2025 7:48 PM, Ezekiel Newren wrote: >On Sat, Sep 20, 2025 at 5:18 PM 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. ``` ## Ezekiel Newren, 2025-09-21 01:24 Subject: Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty Message-ID: URL: https://gitlist.dev/e/CAH%3DZcbDGaxiW%3DQCTrRo3YqxS-rY0e5h5PrnKQt9htJfn4firJA%40mail.gmail.com In-Reply-To: <002c01dc2a95$400315f0$c00941d0$@nexbridge.com> ``` On Sat, Sep 20, 2025 at 7:15 PM 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? ``` ## rsbecker@nexbridge.com, 2025-09-21 03:18 Subject: RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty Message-ID: <003401dc2aa6$623d1420$26b73c60$@nexbridge.com> URL: https://gitlist.dev/e/003401dc2aa6%24623d1420%2426b73c60%24%40nexbridge.com In-Reply-To: ``` On September 20, 2025 9:24 PM, Ezekiel Newren wrote: >On Sat, Sep 20, 2025 at 7:15 PM 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. ``` ## Ezekiel Newren, 2025-09-21 16:49 Subject: Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty Message-ID: URL: https://gitlist.dev/e/CAH%3DZcbA0jpntXjPnrVi13Sz1PipnyBLNWKW4Q5taGEHqBrqj-A%40mail.gmail.com In-Reply-To: <003401dc2aa6$623d1420$26b73c60$@nexbridge.com> ``` On Sat, Sep 20, 2025 at 9:18 PM 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? ``` ## rsbecker@nexbridge.com, 2025-09-21 23:07 Subject: RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty Message-ID: <008501dc2b4c$7f5ea450$7e1becf0$@nexbridge.com> URL: https://gitlist.dev/e/008501dc2b4c%247f5ea450%247e1becf0%24%40nexbridge.com In-Reply-To: ``` On September 21, 2025 12:49 PM, Ezekiel Newren wrote: >On Sat, Sep 20, 2025 at 9:18 PM 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 ``` ## Ezekiel Newren, 2025-09-21 23:42 Subject: Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty Message-ID: URL: https://gitlist.dev/e/CAH%3DZcbAop%3Dz8-zA_aEE%2BsTHErg0gjzYRnqCd3XQF9%3D_TakBK8A%40mail.gmail.com In-Reply-To: <008501dc2b4c$7f5ea450$7e1becf0$@nexbridge.com> ``` On Sun, Sep 21, 2025 at 5:07 PM 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? ``` ## rsbecker@nexbridge.com, 2025-09-22 16:21 Subject: RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty Message-ID: <000001dc2bdc$fa856d40$ef9047c0$@nexbridge.com> URL: https://gitlist.dev/e/000001dc2bdc%24fa856d40%24ef9047c0%24%40nexbridge.com In-Reply-To: ``` On September 21, 2025 7:42 PM, Ezekiel Newren wrote: >On Sun, Sep 21, 2025 at 5:07 PM 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. ```