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

On Sun, Jan 21, 2024 at 9:41 AM Kristof Provost <kp@freebsd.org> wrote:

> On 21 Jan 2024, at 17:26, Poul-Henning Kamp wrote:
> > Alan Somers writes:
> >> * "<something> can't be implemented unless written in rust"
> >>
> >> I don't think anybody has claimed this yet.  But I _have_ made a
> similar claim,
> >> that some things can't be written in C.  I'll elaborate on the project
> that
> >> started this thread: the fusefs test suite.  When I designed the fusefs
> test
> >> suite, I based it around the priniciple of Mocking. [...]
> >
> > Why would such a test-tool live in src rather than ports ?
> >
> It’s entirely reasonable for the test code to live in the same repository
> as the code it tests.
>
> Doing otherwise would make life harder (e.g. how do you establish if a
> test failure is expected with a given src version) for no good reason.
>
> I suspect we may be working with different views of what a test tool does
> here. You may be thinking more along the lines of something like iperf,
> while I’m thinking more of test like this one:
> https://cgit.freebsd.org/src/commit?id=4c84c69ba308b7758d07dc8845b13922ed667e02
>
> I’ll take the opportunity to point out that there’s precedent for using
> non-base languages in tests (e.g. Python, for the test linked above), so
> using Rust code for in-tree tests looks like a reasonable way to get our
> toes wet, without immediately painting ourselves into a corner if it
> doesn’t work out.
>

Exactly. There will be 0 rust in base until we can build rust binaries in
some way. I maintain that the first step for that is using a curated
external toolchain. Tests are a good place to start because they let us
stand up the tooling we need for rust, find out what the problems are, and
maybe get something useful too w/o committing "all in" to rust. It's the
put up or shut up moment: If the rust advocate can't be bothered to even
stand this up (and I'm happy to help with that effort for the build bits)
then there will be 0 rust in base because nobody cared. If that is stood up
and we get tests, we'll have more data to know if it is wise to expand the
experiment or close it down. In addition to being in line with tests in
Python, this is in line with adapting risky technology that we've done in
the past: We tried it out, kept what worked and junked what didn't. It's a
risk for those wanting rust: it may be a failed experiment in which case
their time is wasted. The hypothesis is that rust is useful and that tests
written in rust will be easier / faster / better enough to justify the
extra hassle. Let's test that hypothesis. Tests are easy enough to rewrite
or do without should that hypothesis prove to be flawed.

Even if all the cool kids are doing it, it doesn't mean the cool kids are
wrong. We should not reject the hypothesis on that basis alone. The only
way to know is to try it out and there's enough out-of-tree rust things in
ports to suggest the next logical step is to put the hooks in needed to use
an external toolchain to build something. This is a watered down version of
write cvsupd, to be honest, but one that's testable, measurable, specific
and finite. It gives us data for any follow on choices.

Warner