From: Sam James <sam@gentoo.org>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Michael Orlitzky <michael@orlitzky.com>,
ezekielnewren@gmail.com,
20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im,
Johannes.Schindelin@gmx.de, ben.knoble@gmail.com,
cb@256bit.org, collin.funk1@gmail.com, contact@hacktivis.me,
eschwartz@gentoo.org, git@vger.kernel.org, gitster@pobox.com,
me@ttaylorr.com, newren@gmail.com, phillip.wood123@gmail.com,
pierre-emmanuel.patry@embecosm.com, ps@pks.im
Subject: Re: [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty
Date: Mon, 22 Sep 2025 22:47:03 +0100 [thread overview]
Message-ID: <878qi66tyg.fsf@gentoo.org> (raw)
In-Reply-To: <aNHBIHXYPmS5AvpP@fruit.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> 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.
next prev parent reply other threads:[~2025-09-22 21:47 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-19 17:36 [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty Sergey Fedorov
2025-09-19 17:56 ` Ezekiel Newren
2025-09-19 18:14 ` Collin Funk
2025-09-20 8:24 ` Florian Märkl
2025-09-22 15:59 ` Michael Orlitzky
2025-09-22 16:17 ` Sam James
2025-09-22 21:35 ` brian m. carlson
2025-09-22 21:47 ` Sam James [this message]
2025-09-23 5:05 ` Patrick Steinhardt
2025-09-22 23:23 ` Michael Orlitzky
-- strict thread matches above, loose matches on Subject: below --
2025-09-20 8:29 Sergey Fedorov
2025-09-20 18:39 ` rsbecker
2025-09-20 19:00 ` Ezekiel Newren
2025-09-20 19:25 ` Sam James
2025-09-20 23:17 ` rsbecker
2025-09-20 23:48 ` Ezekiel Newren
2025-09-21 1:15 ` rsbecker
2025-09-21 1:24 ` Ezekiel Newren
2025-09-21 3:18 ` rsbecker
2025-09-21 16:49 ` Ezekiel Newren
2025-09-21 23:07 ` rsbecker
2025-09-21 23:42 ` Ezekiel Newren
2025-09-22 16:21 ` rsbecker
2025-09-04 14:26 Patrick Steinhardt
2025-09-19 18:41 ` John Paul Adrian Glaubitz
2025-09-22 13:01 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878qi66tyg.fsf@gentoo.org \
--to=sam@gentoo.org \
--cc=20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im \
--cc=Johannes.Schindelin@gmx.de \
--cc=ben.knoble@gmail.com \
--cc=cb@256bit.org \
--cc=collin.funk1@gmail.com \
--cc=contact@hacktivis.me \
--cc=eschwartz@gentoo.org \
--cc=ezekielnewren@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.com \
--cc=michael@orlitzky.com \
--cc=newren@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=pierre-emmanuel.patry@embecosm.com \
--cc=ps@pks.im \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).