All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.