{"thread":{"id":"64174","subject":"Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","startedAt":"2025-09-20T08:36:47Z","lastAt":"2025-09-22T16:22:08Z","messageCount":13,"participants":["Sergey Fedorov","rsbecker@nexbridge.com","Ezekiel Newren","Sam James"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"526850","messageId":"8799E6DB-FC85-4F71-A6C1-363D1AC8ED06@macos-powerpc.org","threadId":"64174","inReplyTo":null,"subject":"Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"Sergey Fedorov","fromEmail":"barracuda@macos-powerpc.org","sentAt":"2025-09-20T08:29:47Z","receivedAt":"2025-09-20T08:36:47Z","isPatch":true,"sender":{"key":"barracuda@macos-powerpc.org","avatar":null},"body":"\n> but I'd like to hear what OSes and Architectures you use personally and professionally and why adding Rust would be a bad idea.\n\nI 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.\n\nThose 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.\n\nGit 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.\n\nTo 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.\n\nI 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.\n\nP. 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).\n\nReferences:\nhttps://github.com/rust-lang/rfcs/issues/1312\nhttps://github.com/thepowersgang/mrustc/issues/300\n\nRegards,\nSergey Fedorov\nmacos-powerpc.org\n\n"},{"id":"526863","messageId":"000001dc2a5d$ea10ffe0$be32ffa0$@nexbridge.com","threadId":"64174","inReplyTo":"8799E6DB-FC85-4F71-A6C1-363D1AC8ED06@macos-powerpc.org","subject":"RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-09-20T18:39:28Z","receivedAt":"2025-09-20T18:40:15Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On September 20, 2025 4:30 Am, Sergey Fedorov wrote:\n>> but I'd like to hear what OSes and Architectures you use personally and\n>professionally and why adding Rust would be a bad idea.\n>\n>I am the maintainer of ports for Darwin on PowerPC systems (few past years\nin\n>MacPorts and now in https://github.com/macos-powerpc/powerpc-ports fork)\n>and contributor to GCC (gfortran). I have added the whole of current R\necosystem\n>into MacPorts and a decent support for modern Fortran via FPM.\n>\n>Those systems are still actively used, and thanks to GCC upstream support\nof\n>powerpc-apple-darwin I have been able to keep our ports pretty much on par\n>(occasionally ahead of) what modern macOS has at the moment. A lot of work\nhas\n>been done in past two-three years, including fixing/restoring support for\nppc for\n>several major langs/compilers (gfortran, MLton, SBCL, Ruby, OCaml, Idris2\netc.),\n>build systems etc.\n>\n>Git is essential for the version control, but also for the build systems of\nMacPorts\n>and CMake. Since my powerpc ports rely on MacPorts infrastructure (there\nare\n>40k+ ports), I need a working Git for my workflow.\n>\n>To be clear, I do not object to adding Rust optionally (as I would not\nagainst adding\n>optional modules for any language), but making it mandatory, while Rust is\nstill\n>broken on a few, admittedly edge case, systems, hurts the open-source.\n>\n>I agree with John Paul Adrian that once gccrs becomes properly usable, or\notherwise\n>gcc codegen in Rust acquires support for currently unsupported platforms,\nthings\n>will change.\n>\n>P. S. I have contributed to mrustc, so it is not ideological. Though I do\nthink that\n>ability to bootstrap from source is strictly required for a compiler to be\nsafe, and at\n>the moment bootstrapping of Rust may not yet work for all supported\nplatforms (at\n>least it is not well-tested).\n>\n>References:\n>https://github.com/rust-lang/rfcs/issues/1312\n>https://github.com/thepowersgang/mrustc/issues/300\n\nTo clarify, gcc is not available on all platforms. The overlap where gcc is\nsupported\nand Rust is support is likely high, but more, where gcc is not supported\nthen it is\nhighly unlikely that Rust is supported. mrustc is a difficult more that\nrequires gcc\neven if that is not clearly stated - it does not build with c17, for\nexample. This\ndouble requirement is making the probability of being able to continue to\nsupport\ngit even less for me on NonStop. My team is working hard to push Rust\navailability\nand we realize that gccrs is an easier path, but those two are currently\noutside\nof our control because of complexities in the loader on NonStop.\n\n"},{"id":"526868","messageId":"CAH=ZcbDJR7gJ0tyQ-bk-n+Zid_csED74+X5OkTfbEiy5-_2R-w@mail.gmail.com","threadId":"64174","inReplyTo":"000001dc2a5d$ea10ffe0$be32ffa0$@nexbridge.com","subject":"Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"Ezekiel Newren","fromEmail":"ezekielnewren@gmail.com","sentAt":"2025-09-20T19:00:43Z","receivedAt":"2025-09-20T19:00:56Z","isPatch":true,"sender":{"key":"ezekielnewren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/18313324?v=4"},"body":"On Sat, Sep 20, 2025 at 12:39 PM wrote:\n> To clarify, gcc is not available on all platforms. The overlap where gcc is\n> supported and Rust is support is likely high, but more, where gcc is not\n> supported then it is highly unlikely that Rust is supported. mrustc is a\n> difficult more that requires gcc even if that is not clearly stated - it\n> does not build with c17, for example. This double requirement is making the\n> probability of being able to continue to support git even less for me on\n> NonStop. My team is working hard to push Rust availability and we realize\n> that gccrs is an easier path, but those two are currently outside of our\n> control because of complexities in the loader on NonStop.\n\nIs there a C compiler that works on NonStop and Linux? I ask because\nI'm wondering if code from gccrs could help with augmenting that\ncompiler. From what I understand gccrs is written in C++17, but Rust's\nnative approach uses mrustc to bootstrap, and then the rest of the\nRust compiler is written in Rust. I don't have $500,000 to spare for\ntesting on real NonStop hardware, but if there was a C compiler that\nworked on NonStop and Linux then there'd at least be the possibility\nof people trying to make Rust work with it.\n"},{"id":"526870","messageId":"87qzw10vv9.fsf@gentoo.org","threadId":"64174","inReplyTo":"CAH=ZcbDJR7gJ0tyQ-bk-n+Zid_csED74+X5OkTfbEiy5-_2R-w@mail.gmail.com","subject":"Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"Sam James","fromEmail":"sam@gentoo.org","sentAt":"2025-09-20T19:25:30Z","receivedAt":"2025-09-20T19:25:36Z","isPatch":true,"sender":{"key":"sam@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/11667869?v=4"},"body":"Ezekiel Newren writes:\n\n> On Sat, Sep 20, 2025 at 12:39 PM wrote:\n>> To clarify, gcc is not available on all platforms. The overlap where gcc is\n>> supported and Rust is support is likely high, but more, where gcc is not\n>> supported then it is highly unlikely that Rust is supported. mrustc is a\n>> difficult more that requires gcc even if that is not clearly stated - it\n>> does not build with c17, for example. This double requirement is making the\n>> probability of being able to continue to support git even less for me on\n>> NonStop. My team is working hard to push Rust availability and we realize\n>> that gccrs is an easier path, but those two are currently outside of our\n>> control because of complexities in the loader on NonStop.\n>\n> Is there a C compiler that works on NonStop and Linux? I ask because\n> I'm wondering if code from gccrs could help with augmenting that\n> compiler. From what I understand gccrs is written in C++17, but Rust's\n> native approach uses mrustc to bootstrap, and then the rest of the\n> Rust compiler is written in Rust. I don't have $500,000 to spare for\n> testing on real NonStop hardware, but if there was a C compiler that\n> worked on NonStop and Linux then there'd at least be the possibility\n> of people trying to make Rust work with it.\n\n[Just some small technical notes, it doesn't need a reply.]\n\nGCC defaults to C++17 but is written in C++14 (recently changed from\nC++11). I think the gccrs people may have talked about whether they can\nuse C++17 to make some things easier (I suspect if they requested that,\nit would be approved, at least I'd support it and argue in favour).\n\nmrustc isn't part of any official Rust bootstrap path, Rust upstream\njust use binaries. mrustc currently needs GCC for some trivial reasons\n(like hardcoding some workarounds for bugs w/ GCC-specific flags). I\nsuspect it wouldn't be too hard to get it working with Clang. I don't\nknow how many extensions it relies on in general that may be common but\nnot in the standard.\n\nBut mrustc is written in C++, not C -- AFAIK NonStop has no C++ compiler.\n"},{"id":"526878","messageId":"002001dc2a84$cda40380$68ec0a80$@nexbridge.com","threadId":"64174","inReplyTo":"CAH=ZcbDJR7gJ0tyQ-bk-n+Zid_csED74+X5OkTfbEiy5-_2R-w@mail.gmail.com","subject":"RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-09-20T23:17:50Z","receivedAt":"2025-09-20T23:18:24Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On September 20, 2025 3:01 PM, Ezekiel Newren wrote:\n>On Sat, Sep 20, 2025 at 12:39 PM wrote:\n>> To clarify, gcc is not available on all platforms. The overlap where\n>> gcc is supported and Rust is support is likely high, but more, where\n>> gcc is not supported then it is highly unlikely that Rust is\n>> supported. mrustc is a difficult more that requires gcc even if that\n>> is not clearly stated - it does not build with c17, for example. This\n>> double requirement is making the probability of being able to continue\n>> to support git even less for me on NonStop. My team is working hard to\n>> push Rust availability and we realize that gccrs is an easier path,\n>> but those two are currently outside of our control because of complexities in the\n>loader on NonStop.\n>\n>Is there a C compiler that works on NonStop and Linux? I ask because I'm\n>wondering if code from gccrs could help with augmenting that compiler. From what\n>I understand gccrs is written in C++17, but Rust's native approach uses mrustc to\n>bootstrap, and then the rest of the Rust compiler is written in Rust. I don't have\n>$500,000 to spare for testing on real NonStop hardware, but if there was a C\n>compiler that worked on NonStop and Linux then there'd at least be the possibility\n>of people trying to make Rust work with it.\n\nAll I have is a C++17 compiler. gcc -std=c17 might work for compatibility on Linux but none\nof the gcc extensions work.\n\n"},{"id":"526879","messageId":"CAH=ZcbCf4sWKhOcCe4UkX3Y9VXZ-iHeh4QZ3ExrX1hbn5GE3vA@mail.gmail.com","threadId":"64174","inReplyTo":"002001dc2a84$cda40380$68ec0a80$@nexbridge.com","subject":"Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"Ezekiel Newren","fromEmail":"ezekielnewren@gmail.com","sentAt":"2025-09-20T23:48:28Z","receivedAt":"2025-09-20T23:48:41Z","isPatch":true,"sender":{"key":"ezekielnewren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/18313324?v=4"},"body":"On Sat, Sep 20, 2025 at 5:18 PM wrote:\n> All I have is a C++17 compiler. gcc -std=c17 might work for compatibility on Linux but none\n> of the gcc extensions work.\n\nWhat I meant was: Is there a compiler that can be compiled to both\nNonStop and Linux. What is the name of the C++17 compiler that you use\non NonStop? Is there a Linux or Windows cross compiler that can target\nNonStop?\n"},{"id":"526882","messageId":"002c01dc2a95$400315f0$c00941d0$@nexbridge.com","threadId":"64174","inReplyTo":"CAH=ZcbCf4sWKhOcCe4UkX3Y9VXZ-iHeh4QZ3ExrX1hbn5GE3vA@mail.gmail.com","subject":"RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-09-21T01:15:34Z","receivedAt":"2025-09-21T01:16:07Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On September 20, 2025 7:48 PM, Ezekiel Newren wrote:\n>On Sat, Sep 20, 2025 at 5:18 PM wrote:\n>> All I have is a C++17 compiler. gcc -std=c17 might work for\n>> compatibility on Linux but none of the gcc extensions work.\n>\n>What I meant was: Is there a compiler that can be compiled to both NonStop and\n>Linux. What is the name of the C++17 compiler that you use on NonStop? Is there a\n>Linux or Windows cross compiler that can target NonStop?\n\nWe have c99, c11, c17. The only Windows cross compiler is c99, but that requires\na license from HPE that I cannot provide. There are not non-commercial compilers\navailable that can be used to cross compile. Also, standard configure processing\ndoes not work on Windows for NonStop.\n\n"},{"id":"526884","messageId":"CAH=ZcbDGaxiW=QCTrRo3YqxS-rY0e5h5PrnKQt9htJfn4firJA@mail.gmail.com","threadId":"64174","inReplyTo":"002c01dc2a95$400315f0$c00941d0$@nexbridge.com","subject":"Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"Ezekiel Newren","fromEmail":"ezekielnewren@gmail.com","sentAt":"2025-09-21T01:24:03Z","receivedAt":"2025-09-21T01:24:16Z","isPatch":true,"sender":{"key":"ezekielnewren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/18313324?v=4"},"body":"On Sat, Sep 20, 2025 at 7:15 PM wrote:\n> >What I meant was: Is there a compiler that can be compiled to both NonStop and\n> >Linux. What is the name of the C++17 compiler that you use on NonStop? Is there a\n> >Linux or Windows cross compiler that can target NonStop?\n>\n> We have c99, c11, c17. The only Windows cross compiler is c99, but that requires\n> a license from HPE that I cannot provide. There are not non-commercial compilers\n> available that can be used to cross compile. Also, standard configure processing\n> does not work on Windows for NonStop.\n\nIf C/C++ can be cross compiled from Windows to a NonStop target, then\nwhy does Git need to run on NonStop itself? Why couldn't you use Git\non Windows and then copy the compiled executables to your NonStop\ntargets?\n"},{"id":"526885","messageId":"003401dc2aa6$623d1420$26b73c60$@nexbridge.com","threadId":"64174","inReplyTo":"CAH=ZcbDGaxiW=QCTrRo3YqxS-rY0e5h5PrnKQt9htJfn4firJA@mail.gmail.com","subject":"RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-09-21T03:18:12Z","receivedAt":"2025-09-21T03:18:45Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On September 20, 2025 9:24 PM, Ezekiel Newren wrote:\n>On Sat, Sep 20, 2025 at 7:15 PM wrote:\n>> >What I meant was: Is there a compiler that can be compiled to both\n>> >NonStop and Linux. What is the name of the C++17 compiler that you\n>> >use on NonStop? Is there a Linux or Windows cross compiler that can target\n>NonStop?\n>>\n>> We have c99, c11, c17. The only Windows cross compiler is c99, but\n>> that requires a license from HPE that I cannot provide. There are not\n>> non-commercial compilers available that can be used to cross compile.\n>> Also, standard configure processing does not work on Windows for NonStop.\n>\n>If C/C++ can be cross compiled from Windows to a NonStop target, then why does\n>Git need to run on NonStop itself? Why couldn't you use Git on Windows and then\n>copy the compiled executables to your NonStop targets?\n\nThis is a much longer discussion. Windows is simply not a trusted platform. NonStop\nis. Building on NonStop provides a virus free/malware free container that passes audit\nrequirements for financial transactions that cannot be demonstrated on Windows. I\nhave customers who refuse all attempts at building anything on NonStop.\n\nIn addition, production control cannot be done from windows. There is more to\nlife than Dev in DevSecOps, which is the only thing Windows builds gives you. Unless\ngit runs on NonStop, production artifacts (scripts, configuration, deployed objects)\ncannot be audited and controlled.\n\n"},{"id":"526904","messageId":"CAH=ZcbA0jpntXjPnrVi13Sz1PipnyBLNWKW4Q5taGEHqBrqj-A@mail.gmail.com","threadId":"64174","inReplyTo":"003401dc2aa6$623d1420$26b73c60$@nexbridge.com","subject":"Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"Ezekiel Newren","fromEmail":"ezekielnewren@gmail.com","sentAt":"2025-09-21T16:49:14Z","receivedAt":"2025-09-21T16:49:28Z","isPatch":true,"sender":{"key":"ezekielnewren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/18313324?v=4"},"body":"On Sat, Sep 20, 2025 at 9:18 PM wrote:\n> This is a much longer discussion. Windows is simply not a trusted platform. NonStop\n> is. Building on NonStop provides a virus free/malware free container that passes audit\n> requirements for financial transactions that cannot be demonstrated on Windows. I\n> have customers who refuse all attempts at building anything on NonStop.\n>\n> In addition, production control cannot be done from windows. There is more to\n> life than Dev in DevSecOps, which is the only thing Windows builds gives you. Unless\n> git runs on NonStop, production artifacts (scripts, configuration, deployed objects)\n> cannot be audited and controlled.\n\nCan linux cross compile to NonStop? If so, would Linux be able to pass\naudit requirements?\n\nIt seems like this might be a first mover problem. HPE NonStop doesn't\nwant to support Rust because no one is demanding it from them, but\nengineers don't ask for it (or rather, aren't heard) because HPE\nNonStop refuses to support it. I'll bet NonStop doesn't support Git\nbecause why would they pay for it when you're doing it for them for\nfree. and now people are talking about adding Rust to Git which means\nGit won't work on NonStop and then something breaks and management\nscreams at you to \"fix it\", but you can't because their policy forbade\nyou from using the tools that would allow you to \"fix it\".\n\nAm I telling the story right?\n"},{"id":"526906","messageId":"008501dc2b4c$7f5ea450$7e1becf0$@nexbridge.com","threadId":"64174","inReplyTo":"CAH=ZcbA0jpntXjPnrVi13Sz1PipnyBLNWKW4Q5taGEHqBrqj-A@mail.gmail.com","subject":"RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-09-21T23:07:15Z","receivedAt":"2025-09-21T23:08:12Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On September 21, 2025 12:49 PM, Ezekiel Newren wrote:\n>On Sat, Sep 20, 2025 at 9:18 PM wrote:\n>> This is a much longer discussion. Windows is simply not a trusted\n>> platform. NonStop is. Building on NonStop provides a virus\n>> free/malware free container that passes audit requirements for\n>> financial transactions that cannot be demonstrated on Windows. I have\n>customers who refuse all attempts at building anything on NonStop.\n>>\n>> In addition, production control cannot be done from windows. There is\n>> more to life than Dev in DevSecOps, which is the only thing Windows\n>> builds gives you. Unless git runs on NonStop, production artifacts\n>> (scripts, configuration, deployed objects) cannot be audited and controlled.\n>\n>Can linux cross compile to NonStop? If so, would Linux be able to pass audit\n>requirements?\n>\n>It seems like this might be a first mover problem. HPE NonStop doesn't want to\n>support Rust because no one is demanding it from them, but engineers don't ask\n>for it (or rather, aren't heard) because HPE NonStop refuses to support it. I'll bet\n>NonStop doesn't support Git because why would they pay for it when you're doing\n>it for them for free. and now people are talking about adding Rust to Git which\n>means Git won't work on NonStop and then something breaks and management\n>screams at you to \"fix it\", but you can't because their policy forbade you from using\n>the tools that would allow you to \"fix it\".\n>\n>Am I telling the story right?\n\nNot really no. There is momentum for Rust on NonStop. It just takes time to get\nbudget for the effort. After getting budget, it takes time for the port. I am likely to\nhave some involvement in that, one way or another. NonStop does support git,\nmostly through my ongoing efforts and they do use it extensively. This really is a\ncrucial application and the NonStop team does understand the implications. The\nproblem is that everything takes time, more than git is allowing in this case. I cannot\ndisclose more than that.\n\nYes, people are screaming at me to fix it, which is not easy. The policy is not the\nProblem, but the technical limitations are. It is not a surprise, because I was involved\nIn the POSIX effort when it was first introduced on NonStop, not that many \"in the know\"\nListened to my concerns, which are now having significant consequences.\n\nI am still working all possible angles to see that git stays relevant, and appreciate\nany and all help from any source.\n\nRandall \"The Reluctant Prophet\" Becker\n\n"},{"id":"526907","messageId":"CAH=ZcbAop=z8-zA_aEE+sTHErg0gjzYRnqCd3XQF9=_TakBK8A@mail.gmail.com","threadId":"64174","inReplyTo":"008501dc2b4c$7f5ea450$7e1becf0$@nexbridge.com","subject":"Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"Ezekiel Newren","fromEmail":"ezekielnewren@gmail.com","sentAt":"2025-09-21T23:42:01Z","receivedAt":"2025-09-21T23:42:14Z","isPatch":true,"sender":{"key":"ezekielnewren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/18313324?v=4"},"body":"On Sun, Sep 21, 2025 at 5:07 PM wrote:\n> Not really no. There is momentum for Rust on NonStop. It just takes time to get\n> budget for the effort. After getting budget, it takes time for the port. I am likely to\n> have some involvement in that, one way or another. NonStop does support git,\n> mostly through my ongoing efforts and they do use it extensively. This really is a\n> crucial application and the NonStop team does understand the implications. The\n> problem is that everything takes time, more than git is allowing in this case. I cannot\n> disclose more than that.\n\nAh, thank you for correcting me.\n\n> Yes, people are screaming at me to fix it, which is not easy. The policy is not the\n> Problem, but the technical limitations are. It is not a surprise, because I was involved\n> In the POSIX effort when it was first introduced on NonStop, not that many \"in the know\"\n> Listened to my concerns, which are now having significant consequences.\n\nI think you've mentioned threading as a major technical hurdle for\nRust and GCC somewhere else on the mailing list (correct me if I'm\nwrong). That's why I've worked very hard on single threaded only\ntranslations. Also, I've been targeting Rust version 1.63.0 because\nthat's what debian requires and so my local Rust development is locked\nto that version. I've managed to translate a huge amount of xdiff to\nRust using no Cargo dependencies. I figure if I keep my Rust adoption\neffort as bare bones as possible that'll make it easier for NonStop to\ncatch up to Git's Rust bare minimum requirement. I have been talking\nabout adding cbindgen which pulls in like 40+ dependencies, but that's\na different case because its only purpose is to generate C header\nfiles from parsed Rust files. I can write my Rust in a way that\ncbindgen can be disabled and the generated header files can be checked\ninto Git or acquired somewhere else.\n\nI have 2 questions for you.\nWhat parts of Rust do you think will be easy to port?\nWhat parts of Rust do you think will be difficult to port?\n"},{"id":"526948","messageId":"000001dc2bdc$fa856d40$ef9047c0$@nexbridge.com","threadId":"64174","inReplyTo":"CAH=ZcbAop=z8-zA_aEE+sTHErg0gjzYRnqCd3XQF9=_TakBK8A@mail.gmail.com","subject":"RE: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2025-09-22T16:21:34Z","receivedAt":"2025-09-22T16:22:08Z","isPatch":true,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On September 21, 2025 7:42 PM, Ezekiel Newren wrote:\n>On Sun, Sep 21, 2025 at 5:07 PM wrote:\n>> Not really no. There is momentum for Rust on NonStop. It just takes\n>> time to get budget for the effort. After getting budget, it takes time\n>> for the port. I am likely to have some involvement in that, one way or\n>> another. NonStop does support git, mostly through my ongoing efforts\n>> and they do use it extensively. This really is a crucial application\n>> and the NonStop team does understand the implications. The problem is\n>> that everything takes time, more than git is allowing in this case. I cannot disclose\n>more than that.\n>\n>Ah, thank you for correcting me.\n>\n>> Yes, people are screaming at me to fix it, which is not easy. The\n>> policy is not the Problem, but the technical limitations are. It is\n>> not a surprise, because I was involved In the POSIX effort when it was first\n>introduced on NonStop, not that many \"in the know\"\n>> Listened to my concerns, which are now having significant consequences.\n>\n>I think you've mentioned threading as a major technical hurdle for Rust and GCC\n>somewhere else on the mailing list (correct me if I'm wrong). That's why I've worked\n>very hard on single threaded only translations. Also, I've been targeting Rust version\n>1.63.0 because that's what debian requires and so my local Rust development is\n>locked to that version. I've managed to translate a huge amount of xdiff to Rust\n>using no Cargo dependencies. I figure if I keep my Rust adoption effort as bare\n>bones as possible that'll make it easier for NonStop to catch up to Git's Rust bare\n>minimum requirement. I have been talking about adding cbindgen which pulls in like\n>40+ dependencies, but that's a different case because its only purpose is to generate\n>C header files from parsed Rust files. I can write my Rust in a way that cbindgen can\n>be disabled and the generated header files can be checked into Git or acquired\n>somewhere else.\n>\n>I have 2 questions for you.\n>What parts of Rust do you think will be easy to port?\n>What parts of Rust do you think will be difficult to port?\n\nI will ask the team member who are doing this port for their opinion.\n\nEasy: NonStop is POSIX and has C17, so anything compatible with that should\nnot be difficult.\nHard: Anything that depends on assumptions that gcc works 100% on the\nplatform are hard and have to be worked around, so porting mrustc is considered\nhard on that basis. Our first attempt at porting that did not go well as we have to\nreconstruct the build options, at the very least, from scratch, while not strictly\ndifficult, it is always time consuming to figure out the intention.\n\n"}]}