Date: Sat, 3 Aug 2024 20:41:22 -0400 From: Theron <theron.tarigo@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: <f55375a1-9d49-496d-9446-f879545860c3@gmail.com> In-Reply-To: <CANCZdfoHjYUDeNo78qk6BjHfRgwgDbuuVjD5D9uG6tyCk81-ew@mail.gmail.com> References: <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com> <vdmg5zocd6wqcwc2bvzvzqn4bii2pwdc2r4mgnisukfkboj6nf@f7lv5quu4fjx> <CAOtMX2iDK3uN_oQgzzZAdoOZCfNsnvpefeZvKoTCRmPBhZywzA@mail.gmail.com> <CANCZdfqB1%2B-8BkpKwKoCM%2BzM4mCOFy63yHr1Pco7MnT1DFkb4w@mail.gmail.com> <knnsh327gxyvaajwrymvflnivf3tsnigyqw2d6etfhb4irft3x@ydkh3zmb6uch> <CANCZdfoHjYUDeNo78qk6BjHfRgwgDbuuVjD5D9uG6tyCk81-ew@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
On 8/3/24 13:36, Warner Losh wrote:<br>
<blockquote type="cite"
cite="mid:CANCZdfoHjYUDeNo78qk6BjHfRgwgDbuuVjD5D9uG6tyCk81-ew@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">We already have clang and gcc external tool chains,
so there's a proven
<div class="gmail_quote">
<div>mechanism for that. But there's not a good notion of the
concept "I have</div>
<div>a rust compiler" or "I depend on rust". And there's no
concept of crates</div>
<div>or similar that rust programs use, but that will be one
thorny area that</div>
<div>we'll have to design for. Do we just pull them in and
junk any notion of</div>
<div>a reproducible build for these components into the future
(since any crate</div>
<div>can go away), or do we have a way to build up our own set
of crates</div>
<div>in the tree that the optional components depend on. How
do we do change</div>
<div>management on that if we have multiple programs that
depend on a crate</div>
<div>that's updated? how do we keep things fresh while not
having update</div>
<div>cascades be too burdensome a task. How does this tie into
pkgbase?</div>
<div><br>
</div>
<div>These are the things to think about. We don't need to
solve all of</div>
<div>them, but the Rust ecosystem is quite a bit different
than the C ecosystem</div>
<div>in the details of a number of these points, so we have to
address them</div>
<div>if we want to use Rust in base with the same traits as
all the other bits</div>
<div>in base today (or we need to have a thoughtful discussion
on paradigm</div>
<div>shift and settle on that). To my thinking, pkgbase might
be a good way</div>
<div>to segregate crates that are build from the base tree and
express dependencies</div>
<div>on optional components that use it, and have the ultimate
dependency</div>
<div>be a pkg from ports. <br>
</div>
<div><br>
</div>
<div>These questions and design points aren't hard and aren't
designed to</div>
<div>block anything, but a bare minimum of what we need to
articulate is the</div>
<div>vision for these components. Likely a design document
that spells these</div>
<div>out in some degree of detail (or that we punt in this
phase) would be good</div>
<div>as well. I can help with that as well.<br>
</div>
<div><br>
</div>
<div>Warner<br>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
Theron<br>
</body>
</html>
--------------9V5AylmlYCLzngsaGUCpsxgx--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f55375a1-9d49-496d-9446-f879545860c3>