{"thread":{"id":"64170","subject":"Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","startedAt":"2025-09-19T17:43:07Z","lastAt":"2025-09-23T05:05:14Z","messageCount":10,"participants":["Sergey Fedorov","Ezekiel Newren","Collin Funk","Florian Märkl","Michael Orlitzky","Sam James","brian m. carlson","Patrick Steinhardt"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"526792","messageId":"4C760AB2-C102-43A3-B0B9-11E248F3FCE0@macos-powerpc.org","threadId":"64170","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-19T17:36:08Z","receivedAt":"2025-09-19T17:43:07Z","isPatch":true,"sender":{"key":"barracuda@macos-powerpc.org","avatar":null},"body":"\nThis will be a disaster, please consider not making rust mandatory.\nIt will break git for all systems without rust, in effect killing not only possibility to use GitHub and other git-based services, but also breaking build systems, since many ports – and package managers – rely on git to fetch sources.\nAs for local version control, git could be replaced with some alternative (likely inferior, but at least that is not the end).\nThere is no replacement, AFAIK, for build systems and for git-based online services.\n\nP. S. In case anyone wonders, this is personally relevant for me: I won’t be able to continue contributing to open-source anymore (at least certainly not like in past years) with git being unusable due to broken rust.\n\n"},{"id":"526793","messageId":"CAH=ZcbCUL-rWw5E6p26T0039gs9q-P8iK5fp73-RzTzKiZ0zMQ@mail.gmail.com","threadId":"64170","inReplyTo":"4C760AB2-C102-43A3-B0B9-11E248F3FCE0@macos-powerpc.org","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-19T17:56:38Z","receivedAt":"2025-09-19T17:56:51Z","isPatch":true,"sender":{"key":"ezekielnewren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/18313324?v=4"},"body":"On Fri, Sep 19, 2025 at 11:36 AM Sergey Fedorov\n wrote:\n> This will be a disaster, please consider not making rust mandatory.\n> It will break git for all systems without rust, in effect killing not only possibility to use GitHub and other git-based services, but also breaking build systems, since many ports – and package managers – rely on git to fetch sources.\n> As for local version control, git could be replaced with some alternative (likely inferior, but at least that is not the end).\n> There is no replacement, AFAIK, for build systems and for git-based online services.\n>\n> P. S. In case anyone wonders, this is personally relevant for me: I won’t be able to continue contributing to open-source anymore (at least certainly not like in past years) with git being unusable due to broken rust.\n\nThe mailing list has had extremely heated debates about this, and\nthere are many who would agree and disagree with you. So please try to\nread my comment as a genuine interest in trying to understand your\nsituation. I would like to hear why making Rust mandatory would make\nusing and contributing to Git insurmountable. We know for sure that\nNonStop currently does not support Rust at all, and that there are\nproblems with porting Rust to Gentoo, but I'd like to hear what OSes\nand Architectures you use personally and professionally and why adding\nRust would be a bad idea. Is it corporate policy? Is it that the Rust\ntoolchain doesn't exist for your os/arch? Is it that Rust is a new\nlanguage and isn't as battle tested as C? Something else?\n\nI believe that even \"I don't know Rust and don't want to learn it.\"\nwould be a valid comment to add as well. I think the discussion of\nRust has been so hot because we (the Git community) don't understand\neveryone's situations and how they'll be affected, and what could\npossibly be done to address concerns.\n"},{"id":"526794","messageId":"87segiqpgh.fsf@gmail.com","threadId":"64170","inReplyTo":"CAH=ZcbCUL-rWw5E6p26T0039gs9q-P8iK5fp73-RzTzKiZ0zMQ@mail.gmail.com","subject":"Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"Collin Funk","fromEmail":"collin.funk1@gmail.com","sentAt":"2025-09-19T18:14:54Z","receivedAt":"2025-09-19T18:14:57Z","isPatch":true,"sender":{"key":"collin.funk1@gmail.com","avatar":"https://avatars.githubusercontent.com/u/65689063?v=4"},"body":"Ezekiel Newren writes:\n\n> On Fri, Sep 19, 2025 at 11:36 AM Sergey Fedorov\n> wrote:\n>> This will be a disaster, please consider not making rust mandatory.\n>> It will break git for all systems without rust, in effect killing not only possibility to use GitHub and other git-based services, but also breaking build systems, since many ports – and package managers – rely on git to fetch sources.\n>> As for local version control, git could be replaced with some alternative (likely inferior, but at least that is not the end).\n>> There is no replacement, AFAIK, for build systems and for git-based online services.\n>>\n>> P. S. In case anyone wonders, this is personally relevant for me: I won’t be able to continue contributing to open-source anymore (at least certainly not like in past years) with git being unusable due to broken rust.\n>\n> The mailing list has had extremely heated debates about this, and\n> there are many who would agree and disagree with you. So please try to\n> read my comment as a genuine interest in trying to understand your\n> situation. I would like to hear why making Rust mandatory would make\n> using and contributing to Git insurmountable. We know for sure that\n> NonStop currently does not support Rust at all, and that there are\n> problems with porting Rust to Gentoo, but I'd like to hear what OSes\n> and Architectures you use personally and professionally and why adding\n> Rust would be a bad idea. Is it corporate policy? Is it that the Rust\n> toolchain doesn't exist for your os/arch? Is it that Rust is a new\n> language and isn't as battle tested as C? Something else?\n>\n> I believe that even \"I don't know Rust and don't want to learn it.\"\n> would be a valid comment to add as well. I think the discussion of\n> Rust has been so hot because we (the Git community) don't understand\n> everyone's situations and how they'll be affected, and what could\n> possibly be done to address concerns.\n\nBased on the domain of their email they use MacOS PowerPC. AFAIK LLVM\nhas not supported it for a long time.\n\nCollin\n"},{"id":"526849","messageId":"E2D395CF-ED37-4D96-8C0A-683638FF2058@florianmaerkl.de","threadId":"64170","inReplyTo":"CAH=ZcbCUL-rWw5E6p26T0039gs9q-P8iK5fp73-RzTzKiZ0zMQ@mail.gmail.com","subject":"Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"Florian Märkl","fromEmail":"info@florianmaerkl.de","sentAt":"2025-09-20T08:24:32Z","receivedAt":"2025-09-20T08:25:03Z","isPatch":true,"sender":{"key":"info@florianmaerkl.de","avatar":null},"body":"\n> Ezekiel Newren wrote:\n> \n> I'd like to hear what OSes\n> and Architectures you use personally and professionally and why adding\n> Rust would be a bad idea.\n\nTo add some specific cases from my side as well, problematic platforms include\nMac OS X on ppc as well as OpenBSD/macppc (32-bit). Both of these are still\nrelevant, as OpenBSD is actively maintained on this architecture and Mac OS X\n10.5 is supported by MacPorts, resulting in a system with modern tools that is\nstill able to run and debug certain legacy software.\n\nIn particular, in the Rizin project, we use both platforms regularly to test\nour code for architecture and OS-specific bugs, and we also support them to run\nRizin itself for debugging and analyzing software there.\n\nI do not advocate not adopting Rust because of the language itself, but I think\nit is important to compare the maturity of the compiler and ecosystem to the\nproject that will strictly depend on it."},{"id":"526944","messageId":"20250922155949.27019-1-michael@orlitzky.com","threadId":"64170","inReplyTo":"CAH=ZcbCUL-rWw5E6p26T0039gs9q-P8iK5fp73-RzTzKiZ0zMQ@mail.gmail.com","subject":"Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"Michael Orlitzky","fromEmail":"michael@orlitzky.com","sentAt":"2025-09-22T15:59:49Z","receivedAt":"2025-09-22T16:05:41Z","isPatch":true,"sender":{"key":"michael@orlitzky.com","avatar":null},"body":"> We know for sure that NonStop currently does not support Rust at\n> all, and that there are problems with porting Rust to Gentoo, but\n> I'd like to hear what OSes and Architectures you use personally and\n> professionally and why adding Rust would be a bad idea. Is it\n> corporate policy? Is it that the Rust toolchain doesn't exist for\n> your os/arch? Is it that Rust is a new language and isn't as battle\n> tested as C? Something else?\n\nThere is no problem with supporting rust on Gentoo. Gentoo users build\nfrom source, and rust is a problem for anyone who builds from\nsource. I'm writing this on a riscv/musl system. If there are no\nbinaries for your CPU/libc, let me tell you, it's not fun. And this is\nlike, my job. A normal person would be completely helpless.\n\nNevertheless, the arch support issues are secondary. I'm sure it's a\nlot of fun for the people who are writing rust code to do cargo\nupdates in the two or three directories they work in all day. But I'm\nnot writing rust code, don't care what language git is written in, and\nhave hundreds of other packages to keep up-to-date on multiple\nmachines. I want to be able to use my package manager to do that\nefficiently. You know, the main tangible benefit of using a linux\ndistribution.\n\nBut every distribution is \"packaging\" rust the same way. They're\nbundling random old versions of crates in violation of their own\npolicies because the ecosystem is unstable and the tooling encourages\ntight coupling. By requiring rust, you are require me to go back to\nmanaging dependencies like I'm on Windows XP again. Git is the most\nimportant program I use, but it's not more important than package\nmanagement itself.\n"},{"id":"526947","messageId":"877bxq8nrx.fsf@gentoo.org","threadId":"64170","inReplyTo":"20250922155949.27019-1-michael@orlitzky.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-22T16:17:38Z","receivedAt":"2025-09-22T16:17:43Z","isPatch":true,"sender":{"key":"sam@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/11667869?v=4"},"body":"Michael Orlitzky writes:\n\n>> We know for sure that NonStop currently does not support Rust at\n>> all, and that there are problems with porting Rust to Gentoo, but\n>> I'd like to hear what OSes and Architectures you use personally and\n>> professionally and why adding Rust would be a bad idea. Is it\n>> corporate policy? Is it that the Rust toolchain doesn't exist for\n>> your os/arch? Is it that Rust is a new language and isn't as battle\n>> tested as C? Something else?\n>\n> There is no problem with supporting rust on Gentoo. Gentoo users build\n> from source, and rust is a problem for anyone who builds from\n> source. I'm writing this on a riscv/musl system. If there are no\n> binaries for your CPU/libc, let me tell you, it's not fun. And this is\n> like, my job. A normal person would be completely helpless.\n>\n\nThat is precisely the problem that Eli and I have been describing in\nthis thread (along with some more minor issues for Prefix to figure out,\nand then missing arch support where Rust doesn't support it at all).\n\nHe is referencing issues we brought up earlier in the (various) threads,\nnot plucking it out of thin air.\n\n> Nevertheless, the arch support issues are secondary. I'm sure it's a\n> lot of fun for the people who are writing rust code to do cargo\n> updates in the two or three directories they work in all day. But I'm\n> not writing rust code, don't care what language git is written in, and\n> have hundreds of other packages to keep up-to-date on multiple\n> machines. I want to be able to use my package manager to do that\n> efficiently. You know, the main tangible benefit of using a linux\n> distribution.\n>\n> But every distribution is \"packaging\" rust the same way. They're\n> bundling random old versions of crates in violation of their own\n> policies because the ecosystem is unstable and the tooling encourages\n> tight coupling. By requiring rust, you are require me to go back to\n> managing dependencies like I'm on Windows XP again. Git is the most\n> important program I use, but it's not more important than package\n> management itself.\n\nIndeed, this is all terrible, and I agree with you, of course.\n"},{"id":"526991","messageId":"aNHBIHXYPmS5AvpP@fruit.crustytoothpaste.net","threadId":"64170","inReplyTo":"20250922155949.27019-1-michael@orlitzky.com","subject":"Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-09-22T21:35:28Z","receivedAt":"2025-09-22T21:35:36Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-09-22 at 15:59:49, Michael Orlitzky wrote:\n> There is no problem with supporting rust on Gentoo. Gentoo users build\n> from source, and rust is a problem for anyone who builds from\n> source. I'm writing this on a riscv/musl system. If there are no\n> binaries for your CPU/libc, let me tell you, it's not fun. And this is\n> like, my job. A normal person would be completely helpless.\n\nThis is a problem with languages that bootstrap from earlier versions of\nthemselves. It also happens with other, less common languages. GHC (a\nHaskell runtime) also has this problem and any distro that ships pandoc\nhas to deal with it.\n\nIt is certainly inconvenient, but there is mrustc to help the bootstrap\nprocess. Granted, it does not work everywhere yet, but it should also\nnot be too difficult to make it do so.\n\nI do think the difficulty is worth it, though. With Rust, we're going\nto get code that is thread-safe and memory-safe by the virtue of the\nfact that it compiles and that will allow us to have threading in more\nparts of the code where it might benefit us. I also cannot tell you how\nmany segfaults and null pointer dereferences I've written in Git (some\nin the past week) that are just no longer possible with Rust.\n\nAs my proposal originally mentioned, there is enormous pressure from\ngovernments, security professionals, and large companies to improve\nmemory safety, which I believe are legitimate concerns. If we want Git\nto continue to be used widely, then we need to address those issues and\nRust seems to be the best possible way to do that. I don't think\ncontinuing in C only is going to be viable long term.\n\n> Nevertheless, the arch support issues are secondary. I'm sure it's a\n> lot of fun for the people who are writing rust code to do cargo\n> updates in the two or three directories they work in all day. But I'm\n> not writing rust code, don't care what language git is written in, and\n> have hundreds of other packages to keep up-to-date on multiple\n> machines. I want to be able to use my package manager to do that\n> efficiently. You know, the main tangible benefit of using a linux\n> distribution.\n\nI don't think this is going to happen as you anticipate it will. My\noriginal policy was to target Debian stable's release for a year after\nthe new Debian stable came out and that will make using many crates\nnearly impossible. We are going to have to be _extremely_ careful about\ndependencies in general and the things we are likely to use are things\nlike bindgen and cbindgen, where typically an old version will work just\nfine and which are already packaged in major distros. We are not going\nto be adding dependencies willy-nilly and running `cargo update` every\nother day.\n\n> But every distribution is \"packaging\" rust the same way. They're\n> bundling random old versions of crates in violation of their own\n> policies because the ecosystem is unstable and the tooling encourages\n> tight coupling. By requiring rust, you are require me to go back to\n> managing dependencies like I'm on Windows XP again. Git is the most\n> important program I use, but it's not more important than package\n> management itself.\n\nI expect Debian already packages the crates that we need in acceptable\nversions, and I assume other distros do as well, so I don't anticipate\nthis being a problem for us.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"526994","messageId":"878qi66tyg.fsf@gentoo.org","threadId":"64170","inReplyTo":"aNHBIHXYPmS5AvpP@fruit.crustytoothpaste.net","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-22T21:47:03Z","receivedAt":"2025-09-22T21:47:08Z","isPatch":true,"sender":{"key":"sam@gentoo.org","avatar":"https://avatars.githubusercontent.com/u/11667869?v=4"},"body":"\"brian m. carlson\" writes:\n\n> On 2025-09-22 at 15:59:49, Michael Orlitzky wrote:\n>> There is no problem with supporting rust on Gentoo. Gentoo users build\n>> from source, and rust is a problem for anyone who builds from\n>> source. I'm writing this on a riscv/musl system. If there are no\n>> binaries for your CPU/libc, let me tell you, it's not fun. And this is\n>> like, my job. A normal person would be completely helpless.\n>\n> This is a problem with languages that bootstrap from earlier versions of\n> themselves. It also happens with other, less common languages. GHC (a\n> Haskell runtime) also has this problem and any distro that ships pandoc\n> has to deal with it.\n\nUsually there's nothing too critical in such a language ;)\n\n>\n> It is certainly inconvenient, but there is mrustc to help the bootstrap\n> process. Granted, it does not work everywhere yet, but it should also\n> not be too difficult to make it do so.\n>\n> I do think the difficulty is worth it, though. With Rust, we're going\n> to get code that is thread-safe and memory-safe by the virtue of the\n> fact that it compiles and that will allow us to have threading in more\n> parts of the code where it might benefit us. I also cannot tell you how\n> many segfaults and null pointer dereferences I've written in Git (some\n> in the past week) that are just no longer possible with Rust.\n>\n> As my proposal originally mentioned, there is enormous pressure from\n> governments, security professionals, and large companies to improve\n> memory safety, which I believe are legitimate concerns. If we want Git\n> to continue to be used widely, then we need to address those issues and\n> Rust seems to be the best possible way to do that. I don't think\n> continuing in C only is going to be viable long term.\n>\n>> Nevertheless, the arch support issues are secondary. I'm sure it's a\n>> lot of fun for the people who are writing rust code to do cargo\n>> updates in the two or three directories they work in all day. But I'm\n>> not writing rust code, don't care what language git is written in, and\n>> have hundreds of other packages to keep up-to-date on multiple\n>> machines. I want to be able to use my package manager to do that\n>> efficiently. You know, the main tangible benefit of using a linux\n>> distribution.\n>\n> I don't think this is going to happen as you anticipate it will. My\n> original policy was to target Debian stable's release for a year after\n> the new Debian stable came out and that will make using many crates\n> nearly impossible. We are going to have to be _extremely_ careful about\n> dependencies in general and the things we are likely to use are things\n> like bindgen and cbindgen, where typically an old version will work just\n> fine and which are already packaged in major distros. We are not going\n> to be adding dependencies willy-nilly and running `cargo update` every\n> other day.\n\nThat brings me significant comfort and I'm glad to hear it. I hope\nothers agree with your position on having significant restraint on the\nuse of external crates.\n\ngit has always been quite good about dependencies pre-Rust.\n\n>\n>> But every distribution is \"packaging\" rust the same way. They're\n>> bundling random old versions of crates in violation of their own\n>> policies because the ecosystem is unstable and the tooling encourages\n>> tight coupling. By requiring rust, you are require me to go back to\n>> managing dependencies like I'm on Windows XP again. Git is the most\n>> important program I use, but it's not more important than package\n>> management itself.\n>\n> I expect Debian already packages the crates that we need in acceptable\n> versions, and I assume other distros do as well, so I don't anticipate\n> this being a problem for us.\n\nYes, I expect on our end in Gentoo, that we'll probably need to use this\nto finally migrate to a Debian-style handling of crates, though that's\nnot your problem.\n"},{"id":"527006","messageId":"92bdf57fa8ca49159db3e3384784aa2538a3b48a.camel@orlitzky.com","threadId":"64170","inReplyTo":"aNHBIHXYPmS5AvpP@fruit.crustytoothpaste.net","subject":"Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"Michael Orlitzky","fromEmail":"michael@orlitzky.com","sentAt":"2025-09-22T23:23:31Z","receivedAt":"2025-09-22T23:23:36Z","isPatch":true,"sender":{"key":"michael@orlitzky.com","avatar":null},"body":"On Mon, 2025-09-22 at 21:35 +0000, brian m. carlson wrote:\n> On 2025-09-22 at 15:59:49, Michael Orlitzky wrote:\n> > There is no problem with supporting rust on Gentoo. Gentoo users build\n> > from source, and rust is a problem for anyone who builds from\n> > source. I'm writing this on a riscv/musl system. If there are no\n> > binaries for your CPU/libc, let me tell you, it's not fun. And this is\n> > like, my job. A normal person would be completely helpless.\n> \n> This is a problem with languages that bootstrap from earlier versions of\n> themselves. It also happens with other, less common languages. GHC (a\n> Haskell runtime) also has this problem and any distro that ships pandoc\n> has to deal with it.\n\nSpectacular example.\n\nIn Gentoo we support the following arches: alpha, amd64, arm, arm64,\nhppa, loong, m68k, mips, ppc, ppc64, riscv, s390, sparc, and x86. We\nsupport both glibc and musl, for 23 arch/libc combinations (we don't\nsupport musl on every arch).\n\nPandoc supports: amd64, arm64, ppc64, riscv and x86, but only on glibc.\nThat's 5 out of 23. If you're able to use GHC 9.2 released in 2021,\nthat is. Otherwise it's 0 out of 23. No one \"has to deal with\"\nanything.\n\nCoincidentally, I am one of only a few people to bootstrap a modern GHC\non riscv/musl:\n\n https://wiki.gentoo.org/wiki/User:Mjo/GHC_binary_packages\n\nKnowing the amount of work involved, I can promise that if Git switched\nto Haskell today, it would be our users who would have to deal with...\nnot having Git any more.\n\nI agree completely when it comes to the benefits of static typing and\nmemory safety. (I've been writing Haskell for 15 years, after all.) But\nfor the time being, all of the cures are worse than the disease.\n"},{"id":"527022","messageId":"aNIqgghQwyWV7Tis@pks.im","threadId":"64170","inReplyTo":"878qi66tyg.fsf@gentoo.org","subject":"Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-09-23T05:05:06Z","receivedAt":"2025-09-23T05:05:14Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Sep 22, 2025 at 10:47:03PM +0100, Sam James wrote:\n> \"brian m. carlson\" writes:\n> > I don't think this is going to happen as you anticipate it will. My\n> > original policy was to target Debian stable's release for a year after\n> > the new Debian stable came out and that will make using many crates\n> > nearly impossible. We are going to have to be _extremely_ careful about\n> > dependencies in general and the things we are likely to use are things\n> > like bindgen and cbindgen, where typically an old version will work just\n> > fine and which are already packaged in major distros. We are not going\n> > to be adding dependencies willy-nilly and running `cargo update` every\n> > other day.\n> \n> That brings me significant comfort and I'm glad to hear it. I hope\n> others agree with your position on having significant restraint on the\n> use of external crates.\n> \n> git has always been quite good about dependencies pre-Rust.\n\nI certainly echo brian's sentiment here. Rust dependencies are easy to\nuse, but they are also one part that worries me quite significantly due\nto multiple reasons:\n\n - Pulling in many dependencies opens us up for supply chain attacks.\n\n - Every single dependency is a source for vulnerabilities in general.\n We're already good enough in creating these ourselves.\n\n - Dependencies may have hard requirements on the Rust version,\n requiring us to bump the minimum required toolchain version.\n\n - In general, I'm not a fan of having even dozens of dependencies. It\n causes bloat and externalizes a bunch of knowledge.\n\nSo I think we should and need to be very conservative about adding any\nnew dependencies. There will be cases where it makes sense, but every\nnew dependency should be well-reasoned.\n\nAfter this patch series lands, one of the next steps will also be to add\na policy for how we want to use Rust in the Git project. brian has\nalready written such a policy (see e.g. [1]), and it already mentions\nthat we'll need to be careful about adding dependencies. Might be worth\nit to flesh that part out a bit more, but that's something we can\ndiscuss at a later point.\n\nPatrick\n\n[1]: <6d065f550fe871cf010409f7bd2a63438cf52723.1756496539.git.gitgitgadget@gmail.com>\n"}]}