From nobody Sun Aug 04 00:54:47 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Wc1Lv114Xz5Rh53 for ; Sun, 04 Aug 2024 00:55:03 +0000 (UTC) (envelope-from joesuf4@gmail.com) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Wc1Ls47HTz4b8C for ; Sun, 4 Aug 2024 00:55:01 +0000 (UTC) (envelope-from joesuf4@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=RUBu1ON6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of joesuf4@gmail.com designates 2a00:1450:4864:20::332 as permitted sender) smtp.mailfrom=joesuf4@gmail.com Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-4280c55e488so25966525e9.0 for ; Sat, 03 Aug 2024 17:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722732898; x=1723337698; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WM/ONP++piTyJK4vIPpRyQj3BIYLbntT3spoCoOA1zw=; b=RUBu1ON60MJY74t41A1KKigmz2lgMI5CtI1E0g9nOIez7bFIQYTiHEKNAtQbbZuL4B riWgSVOgga0H8G9CrrXbjyR9OzAyUg2VLU2zO0D3eVxpvjEHUf6rtXd1Q+PCymYxbZf+ RTM9jp7qqJh96jIgBSGvS7DJryERkjzJHfRhs6VhOBsxlJuVT6rEqMroq7q0DzyFImjd mP32L5t8U+xVmyR/JTtDOqOyzL9F0KngW8ENb/mGbiQtjwOtZxgB5RlO5IFx1CTP6nEH E07aOHqBnAl/H20bTPB8ur45dRwS9mpvZacFZm/2LNYqtw2/+/s77rVoLAMZnY9Qbm7B 5wKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722732898; x=1723337698; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WM/ONP++piTyJK4vIPpRyQj3BIYLbntT3spoCoOA1zw=; b=A8IEAHvYL4xwKGSnTuZgqCUDV3G/Z1WmcrQr1/53XB+NIknSfZCKbBThOTFsUAJde8 oMWwDrRd/oH/SFJGDS7WvcA4+1+bI6rloRZB0LQsjgKjGOPhA0ywznyPpMIBXtNnuW4+ Hzm0zhnCPGc6Xa2VX3YNSNBfuuovCW8ho73BxuHRaNFQOb1cNlnZ4rFJZ0OAwykxWHuQ a71J32nA+5YILaq7ikxM6SZyVlRrCkaOKjFQ4TI7T3AcgmJPVir0HDNtvabwWSvLoSPu /1xUMekAeuNq3gR5V7QIbVdh6hdRjLi3s3SOnaVV+3wUT1SBfLuaWrtAvuVRG4r9zl5n rP3g== X-Gm-Message-State: AOJu0YwQDbnyfVOA+MtXLxOfrbpLLSDZ+prPD+WG7V3nPkXWbrfC0LAU e6BgBz9ROuyicdUj79Hf6cE0itAEnqnhd/64Ocx1WzaYp/YhHT96zZZ3NChIyTheegMWBUQ/gBp K8vRlhZ2ervv2KOy8L785QQkDEtA= X-Google-Smtp-Source: AGHT+IEbJw6Dp8y0BJ06WTCrtn12uAg2l+N24U8JCvG6KwhGw2AAEZ0xYHUen6JxYHbgk0rWS3b/ASn26dXYaEzkC1k= X-Received: by 2002:a05:600c:3b21:b0:428:6ac:426e with SMTP id 5b1f17b1804b1-428e4713fe7mr71519065e9.5.1722732898336; Sat, 03 Aug 2024 17:54:58 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Joe Schaefer Date: Sat, 3 Aug 2024 20:54:47 -0400 Message-ID: Subject: Re: The Case for Rust (in the base system) To: Theron Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="00000000000072c4d2061ed10222" X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.99)[-0.991]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MISSING_XM_UA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TAGGED_RCPT(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::332:from] X-Rspamd-Queue-Id: 4Wc1Ls47HTz4b8C --00000000000072c4d2061ed10222 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Have fun with the less than zero backwards compatibility every new quarter. On Sat, Aug 3, 2024 at 8:42=E2=80=AFPM Theron wro= te: > On 8/3/24 13:36, Warner Losh wrote: > > We already have clang and gcc external tool chains, so there's a proven > > mechanism for that. But there's not a good notion of the concept "I have > a rust compiler" or "I depend on rust". And there's no concept of crates > or similar that rust programs use, but that will be one thorny area that > we'll have to design for. Do we just pull them in and junk any notion of > a reproducible build for these components into the future (since any crat= e > can go away), or do we have a way to build up our own set of crates > in the tree that the optional components depend on. How do we do change > management on that if we have multiple programs that depend on a crate > that's updated? how do we keep things fresh while not having update > cascades be too burdensome a task. How does this tie into pkgbase? > > These are the things to think about. We don't need to solve all of > them, but the Rust ecosystem is quite a bit different than the C ecosyste= m > in the details of a number of these points, so we have to address them > if we want to use Rust in base with the same traits as all the other bits > in base today (or we need to have a thoughtful discussion on paradigm > shift and settle on that). To my thinking, pkgbase might be a good way > to segregate crates that are build from the base tree and express > dependencies > on optional components that use it, and have the ultimate dependency > be a pkg from ports. > > These questions and design points aren't hard and aren't designed to > block anything, but a bare minimum of what we need to articulate is the > vision for these components. Likely a design document that spells these > out in some degree of detail (or that we punt in this phase) would be goo= d > as well. I can help with that as well. > > Warner > > > Rust must be adapted to the established practice of keeping base > dependencies in-tree, not the other way around. Whatever shift of thinki= ng > is required within Rust for cooperating with this kind of stability withi= n > a project will be good for the Rust ecosystem as well. > > > Theron > --00000000000072c4d2061ed10222 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Have fun with the less than zero backwards compatibility = every new quarter.

On Sat, Aug 3, 2024 at 8:42=E2=80=AFPM Theron <theron.tarigo@gmail.com> wr= ote:
=20 =20 =20
On 8/3/24 13:36, Warner Losh wrote:
=20
We already have clang and gcc external tool chains, so there's a proven
mechanism for that. But there's not a good notion of the concept "I have
a rust compiler" or "I depend on rust". And t= here's no concept of crates
or similar that rust programs use, but that will be one thorny area that
we'll have to design for. Do we just pull them in and junk any notion of
a reproducible build for these components into the future (since any crate
can go away), or do we have a way to build up our own set of crates
in the tree that the optional components depend on. How do we do change
management on that if we have multiple programs that depend on a crate
that's updated? how do we keep things fresh while not having update
cascades be too burdensome a task. How does this tie into pkgbase?

These are the things to think about. We don't need to solve all of
them, but the Rust ecosystem is quite a bit different than the C ecosystem
in the details of a number of these points, so we have to address them
if we want to use Rust in base with the same traits as all the other bits
in base today (or we need to have a thoughtful discussion on paradigm
shift and settle on that). To my thinking, pkgbase might be a good way
to segregate crates that are build from the base tree and express dependencies
on optional components that use it, and have the ultimate dependency
be a pkg from ports.

These questions and design points aren't hard and aren&#= 39;t designed to
block anything, but a bare minimum of what we need to articulate is the
vision for these components. Likely a design document that spells these
out in some degree of detail (or that we punt in this phase) would be good
as well. I can help with that as well.

Warner

Rust must be adapted to the established practice of keeping base dependencies in-tree, not the other way around.=C2=A0 Whatever shift of thinking is required within Rust for cooperating with this kind of stability within a project will be good for the Rust ecosystem as well.


Theron
--00000000000072c4d2061ed10222--