On Wednesday, January 10, 2024 7:59 PM, Elijah Newren wrote: >On Wed, Jan 10, 2024 at 3:52 PM <rsbecker@xxxxxxxxxxxxx> wrote: >> >> On Wednesday, January 10, 2024 5:26 PM, Taylor Blau wrote: >> >On Wed, Jan 10, 2024 at 05:15:53PM -0500, rsbecker@xxxxxxxxxxxxx wrote: >> >> Just a brief concern: Rust is not broadly portable. Adding another >> >> dependency to git will remove many existing platforms from future releases. >> >> Please consider this carefully before going down this path. >> > >> >I was hoping to hear from you as one of the few (only?) folks who >> >participate on the list and represent HPE NonStop users. >> > >> >I'm curious which if any of the compiler frontends that I listed in >> >my earlier email would work for you. >> >> Unfortunately, none of the compiler frontends listed previously can be built for >NonStop. These appear to all require gcc either directly or transitively, which cannot >be ported to NonStop. I do not expect this to change any time soon - and is outside >of my control anyway. An attempt was made to port Rust but it did not succeed >primarily because of that dependency. Similarly, Golang is also not portable to >NonStop because of architecture assumptions made by the Go team that cannot be >satisfied on NonStop at this time. If some of the memory/pointer issuese the >primary concern, c11 might be something acceptable with smart pointers. C17 will >eventually be deployable, but is not available on most currently supported OS >versions on the platform. > >Would you be okay with the following alternative: requiring that all Rust code be >optional for now? > >(In other words, allow you to build with USE_RUST=0, or something like that. And >then we have both a Rust and a C implementation of anything that is required for >backward compatibility, while any new Rust-only stuff would not be included in >your build.) To address the immediate above, I assume this means that platform maintainers will be responsible for developing non-portable implementations that duplicate Rust functionality, which arguably may not be possible. We do have $DAYJOBS and the expectation that duplicate implementation are cost effective or even viable is a huge assumption that may not be attainable. One of the key benefits of git is the ability to deploy it virtually anywhere on virtually any platform - and mirror repositories anywhere for resiliency purposes. It currently runs on (almost) every current platform because it does not have dependencies on Linux-only compilers and tools. Except for LFS, which is Golang, and I do not have access to that functionality, anyone with a C compiler can deploy git processes in their environment. By adding Rust (or any other gcc-only dependency), it eliminates the primary benefit of git. I am honestly very disappointed with this direction and think this detracts significantly from the primary value proposition that git offers: specifically, that we can take any developer from any platform and move them anywhere else without having to design new processes or teach them new processes for their workflows (this comes up at every major customer with whom I interact). I think this direction is a fundamental mistake and will rapidly limit (or eliminate) git's long-term viability. To be honest, if I saw this direction when deciding which VCS to deploy, I would reconsider git and start looking around for another more portable option. It hurts to even contemplate this direction. Please do not do this.
