git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

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