From nobody Sun Aug 4 00:41:22 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 4Wc14b0SWnz5Rg53 for ; Sun, 04 Aug 2024 00:42:39 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 4Wc14Z1W9Bz4Yhd for ; Sun, 4 Aug 2024 00:42:38 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=mimrF4Ug; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of theron.tarigo@gmail.com designates 2607:f8b0:4864:20::730 as permitted sender) smtp.mailfrom=theron.tarigo@gmail.com Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-7a1d81dc0beso596712385a.2 for ; Sat, 03 Aug 2024 17:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722732156; x=1723336956; darn=freebsd.org; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:sender:from:to:cc:subject:date :message-id:reply-to; bh=3YsizotCreUnHpWq155YO402V8FUSet2QOHH+YJ71MA=; b=mimrF4UgWPdKOVft/X3OwzrVRzprklhdW+HdEKLHLl70sNTY4SyrBVFcixwt9nO/xZ aibmHXF+cu5jPh3aqU5HCyE3sADPDUdhZCykIvuUnao46LIGrHiE3p0bWdLSvGCkaI1I wUjTahnIASNXlCk4v7QTyuOWFr+iz3nM5afNRttTa6AfufOKQlk5OFjfCz53+syMYu5B AlHGRa7U5mYzkwHv6JZySivLuqVjtZc26bmDTeBdyWgiGKhN6je9ung4/wz6UtKZ7m5+ YgWdwu5a/A4QHALKAaH6T7TaFRYrkuZ8PK8LqHFrL7PK4cf+9zzJyviLv9ttD+hgvRZx Z/eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722732156; x=1723336956; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3YsizotCreUnHpWq155YO402V8FUSet2QOHH+YJ71MA=; b=EwEWw8H1AkClfiBBI8uYJxYrNVw2t1Oo4n361sOY6fWd0REQjF1afliy7JuVtY8eHV eCuXjSeGrkssunI67C4J3H1XdGaPuucFMstINtWFspkSzwd88N3mFFigUnL5+2+vgY71 VM0+E3g33xQcwRcCxFwecmglvFI/zVTxdeFc7g9pXfs3qsdF9XWx6dWla1XEXz1xz/7K MMwNBIu8q5Bs2agr8XS9rFCfz1dGpUbawQwnhG+m+y5dOp4+SBcX7NUHfenq0eeJVDUT cIFazKkIgV9OMAb7mslsqPFXGpVljfb36/XROoE+lhXE/QNamSdI1gpmT1R9ldXMIgDp ohOA== X-Gm-Message-State: AOJu0YyP/z+nLJkWZ6DNy6+dXGM5u6RlFX2sLWVwYj9nx8Chd8Bq4Eyl mzDLaCk8BzRo6EMbjICxpt4YCH2U35Q7mGfn7aFUgbI81xxsF0KDtfx1UQ== X-Google-Smtp-Source: AGHT+IFNFfxH9YIknytJ9SIn0w/ZY0MNRG7INZK6cMaMMUbBT2roDV9p6weBapTXU/S/wkCIyITnLw== X-Received: by 2002:a05:620a:3712:b0:79e:ff31:5876 with SMTP id af79cd13be357-7a34ef47009mr1017493285a.35.1722732156130; Sat, 03 Aug 2024 17:42:36 -0700 (PDT) Received: from [192.168.2.2] ([71.173.77.29]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7a34f6dca50sm215308485a.16.2024.08.03.17.42.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Aug 2024 17:42:35 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------9V5AylmlYCLzngsaGUCpsxgx" Message-ID: Date: Sat, 3 Aug 2024 20:41:22 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: The Case for Rust (in the base system) To: freebsd-hackers@freebsd.org References: Content-Language: en-US From: Theron In-Reply-To: X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.16 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(0.83)[0.831]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TAGGED_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::730:from] X-Rspamd-Queue-Id: 4Wc14Z1W9Bz4Yhd This is a multi-part message in MIME format. --------------9V5AylmlYCLzngsaGUCpsxgx Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 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'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.  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 --------------9V5AylmlYCLzngsaGUCpsxgx Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 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'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.  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
--------------9V5AylmlYCLzngsaGUCpsxgx--