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

[<rsbecker@nexbridge.com>]

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.