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

From: Sam James <[email-masked]>
Date: Mon, 22 Sep 2025 22:47:03 +0100

"brian m. carlson" <[email-masked]> writes:

> 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 ;)

>
> 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.

>
>> 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.