Re: The Case for Rust (in the base system)

On Sat, Aug 03, 2024 at 11:36:52AM -0600, 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.

Lets take a look at 'Rust in FreeBSD base' from different angle.

Instead of starting with integration into the build system, lets decide
which useful things can we implement in Rust.  Lets ignore the problems
of integrating (not yet written) code into the build, the problem of
crates that should be vendored, etc.

What would be a task that needs to be solved, and which implementation
in Rust would utilize the hyped memory safety, type system, and all other
goodies of the language?  It is quite desirable, IMO, for this to be a
solution for a problem, instead of rewriting existing tool in Rust.
We do not want to produce more exa/eza/fd/bat/gstat-rs etc (I am not
claiming that these are even slightly wrong, just that we want new stuff
and not reimplementations of existing stuff).

It is clearly should be a userspace thing, because producing idiomatic
Rust bindings for kernel is a huge task on its own. I once thought
about re-writing (sigh) rtld in Rust, perhaps with utilizing existing
rtld/libc/rust stdlib for the new rtld bootstrap, but this feels like
April 1 joke instead of useful thing.  And it is still a rewrite.