RE: [TOPIC 01/11] Rust

>On 23/09/2024 13:17, rsbecker@nexbridge.com wrote:
>> On September 22, 2024 10:26 PM, Sean Allred wrote:
>>
>> The GCC dependency, which does not currently exist in git, is
>> independent of Rust. > Rust has its own rules and runtime. The issue
>> here is that the Rust team gets to decide what platforms can
>> participate, NOT the platform maintainers. No matter what my intent,
>> or resources, I cannot get the Rust team to "Allow" a port.
>> In
>> many ways, this is egregious and is a policy issue entirely on Rust, not us.
>> We
>> want to do a Rust port but are simply not allowed/approved. It is
>> their policy.
>
>I'm hearing that there is a fundamental incompatibility between some aspect of the
>NonStop platform and rust's requirements for supported platforms. Does that
>mean it is likely that rust will never be available on NonStop?

>> I agree that it is not a good policy to never add new dependencies.
>> However, Dependencies must be reasonable and give the platforms a
>> chance, at least, to adapt. We cannot in the case of Rust. The problem
>> is not actually that we can do without new features that are in Rust
>> but not C. The problem is when there are CVEs. Suppose a severe CVE
>> happens that is fixed in a Rust component but referenced by a C
>> component or somehow intertwined. The fix to the CVE becomes
>> unavailable and git gets thrown off the platform. That is the reality
>> of how insidious CVEs are when it meets corporate policy. I am
>> primarily trying to protect from that.
>
>In that scenario there is nothing preventing a different fix being implemented for an
>older version of git running on a platform that does not support rust. It's likely that
>such a fix would need to come from the community using that platform rather than
>upstream which would represent an additional cost for users that have previously
>been relying on the upstream to provide security updates.

>
>> Telling 10-20000 users that their core bit of infrastructure is
>> insecure and not fixable is not a tenable position. However, it is
>> hard to defend the community when the git team is hell-bent on this
>> particular decision. What do you need to understand here?
>> It is a small community with a large number of users in key financial
>> institutions that have a very conservative adoption policy and an even
>> more conservative hardware vendors.
>
>I'm struggling to understand why such a conservative community needs access to
>the latest version of git. I'd have thought that key financial institutions should be
>able to fund someone to backport security updates to their critical systems.

>
>> Again, it is not the gcc dependency. We have been coping with c99 and
>> will have c11 shortly. It is Rust itself that is exclusionary. It
>> might be easier to write new functionality in Rust - it is easier in
>> Java, Perl, and Python too. Why Rust? Because someone wants it, not
>> because you cannot implement the functionality.
>
>It may be true in theory that anything one can write in rust could be written in C
>instead but in I'm not sure it is true in practice. In previous discussions multi-
>threading has been mentioned as an example of something that is sufficiently
>difficult to get right in C that contributors are not willing to implement whereas they
>would be happy to do so in rust.

>
>I believe that those advocating for using rust are doing so because they believe it will
>benefit both contributors and users. The problem we have to wrestle with is
>whether those benefits outweigh the cost to the relatively small proportion of users
>who do not have access to rust on their platform.