Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty
- From
Sam James <sam@gentoo.org>
- Date
- Sep 22, 2025, 21:47 UTC
- Message-ID
- <878qi66tyg.fsf@gentoo.org>
- In-Reply-To
- <aNHBIHXYPmS5AvpP@fruit.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 11 quoted lines
> On 2025-09-22 at 15:59:49, Michael Orlitzky wrote: >> There is no problem with supporting rust on Gentoo. Gentoo users build >> from source, and rust is a problem for anyone who builds from >> source. I'm writing this on a riscv/musl system. If there are no >> binaries for your CPU/libc, let me tell you, it's not fun. And this is >> like, my job. A normal person would be completely helpless. > > This is a problem with languages that bootstrap from earlier versions of > themselves. It also happens with other, less common languages. GHC (a > Haskell runtime) also has this problem and any distro that ships pandoc > has to deal with it.
Usually there's nothing too critical in such a language ;)
Show 37 quoted lines
> > It is certainly inconvenient, but there is mrustc to help the bootstrap > process. Granted, it does not work everywhere yet, but it should also > not be too difficult to make it do so. > > I do think the difficulty is worth it, though. With Rust, we're going > to get code that is thread-safe and memory-safe by the virtue of the > fact that it compiles and that will allow us to have threading in more > parts of the code where it might benefit us. I also cannot tell you how > many segfaults and null pointer dereferences I've written in Git (some > in the past week) that are just no longer possible with Rust. > > As my proposal originally mentioned, there is enormous pressure from > governments, security professionals, and large companies to improve > memory safety, which I believe are legitimate concerns. If we want Git > to continue to be used widely, then we need to address those issues and > Rust seems to be the best possible way to do that. I don't think > continuing in C only is going to be viable long term. > >> Nevertheless, the arch support issues are secondary. I'm sure it's a >> lot of fun for the people who are writing rust code to do cargo >> updates in the two or three directories they work in all day. But I'm >> not writing rust code, don't care what language git is written in, and >> have hundreds of other packages to keep up-to-date on multiple >> machines. I want to be able to use my package manager to do that >> efficiently. You know, the main tangible benefit of using a linux >> distribution. > > I don't think this is going to happen as you anticipate it will. My > original policy was to target Debian stable's release for a year after > the new Debian stable came out and that will make using many crates > nearly impossible. We are going to have to be _extremely_ careful about > dependencies in general and the things we are likely to use are things > like bindgen and cbindgen, where typically an old version will work just > fine and which are already packaged in major distros. We are not going > to be adding dependencies willy-nilly and running `cargo update` every > other day.
That brings me significant comfort and I'm glad to hear it. I hope others agree with your position on having significant restraint on the use of external crates.
git has always been quite good about dependencies pre-Rust.
Show 12 quoted lines
> >> But every distribution is "packaging" rust the same way. They're >> bundling random old versions of crates in violation of their own >> policies because the ecosystem is unstable and the tooling encourages >> tight coupling. By requiring rust, you are require me to go back to >> managing dependencies like I'm on Windows XP again. Git is the most >> important program I use, but it's not more important than package >> management itself. > > I expect Debian already packages the crates that we need in acceptable > versions, and I assume other distros do as well, so I don't anticipate > this being a problem for us.
Yes, I expect on our end in Gentoo, that we'll probably need to use this to finally migrate to a Debian-style handling of crates, though that's not your problem.