Date: Sun, 21 Jan 2024 12:52:04 -0700 From: Warner Losh <imp@bsdimp.com> To: Kristof Provost <kp@freebsd.org> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Alan Somers <asomers@freebsd.org>, George Mitchell <george+freebsd@m5p.com>, freebsd-hackers@freebsd.org Subject: Re: The Case for Rust (in the base system) Message-ID: <CANCZdfo_MU4yo_4dvvTB%2BQf3JFT6EVEYZ4cmFHa%2BEJEjs_1crA@mail.gmail.com> In-Reply-To: <4EF67303-A995-457A-990F-A4972C23EA80@FreeBSD.org> References: <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com> <1673801705774097@mail.yandex.ru> <CANCZdfpqWgvV_RCvVO_pvTrmajQFspW%2BQ9TM_Ok3JrXZAfeAfA@mail.gmail.com> <ef4ad207-5899-42b6-8728-bc46f1417e9e@antonovs.family> <202401210751.40L7pWEF011188@critter.freebsd.dk> <40bc1694-ee00-431b-866e-396e9d5c07a2@m5p.com> <CAOtMX2hppfdu5ypDdGpfw_QDcd1rwJEeyVfSk9ogFEm7CiV6Kw@mail.gmail.com> <202401211626.40LGQDim013134@critter.freebsd.dk> <4EF67303-A995-457A-990F-A4972C23EA80@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000acf412060f7a0c63 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jan 21, 2024 at 9:41=E2=80=AFAM Kristof Provost <kp@freebsd.org> wr= ote: > 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 fusef= s > test > >> suite, I based it around the priniciple of Mocking. [...] > > > > Why would such a test-tool live in src rather than ports ? > > > It=E2=80=99s entirely reasonable for the test code to live in the same re= pository > 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=E2=80=99m thinking more of test like this one: > https://cgit.freebsd.org/src/commit?id=3D4c84c69ba308b7758d07dc8845b13922= ed667e02 > > I=E2=80=99ll take the opportunity to point out that there=E2=80=99s prece= dent 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=E2=80=99t 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 --000000000000acf412060f7a0c63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jan 21, 2024 at 9:41=E2=80=AF= AM Kristof Provost <<a href=3D"mailto:kp@freebsd.org">kp@freebsd.org</a>= > wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px = 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2= 1 Jan 2024, at 17:26, Poul-Henning Kamp wrote:<br> > Alan Somers writes:<br> >> * "<something> can't be implemented unless written = in rust"<br> >><br> >> I don't think anybody has claimed this yet.=C2=A0 But I _have_= made a similar claim,<br> >> that some things can't be written in C.=C2=A0 I'll elabora= te on the project that<br> >> started this thread: the fusefs test suite.=C2=A0 When I designed = the fusefs test<br> >> suite, I based it around the priniciple of Mocking. [...]<br> ><br> > Why would such a test-tool live in src rather than ports ?<br> ><br> It=E2=80=99s entirely reasonable for the test code to live in the same repo= sitory as the code it tests.<br> <br> 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.<br> <br> I suspect we may be working with different views of what a test tool does h= ere. You may be thinking more along the lines of something like iperf, whil= e I=E2=80=99m thinking more of test like this one: <a href=3D"https://cgit.= freebsd.org/src/commit?id=3D4c84c69ba308b7758d07dc8845b13922ed667e02" rel= =3D"noreferrer" target=3D"_blank">https://cgit.freebsd.org/src/commit?id=3D= 4c84c69ba308b7758d07dc8845b13922ed667e02</a><br> <br> I=E2=80=99ll take the opportunity to point out that there=E2=80=99s precede= nt 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=E2=80=99t work out.<br></blockquote><div><br></div><div>Exactly. T= here 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 toolchai= n. 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 o= r 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) the= n there will be 0 rust in base because nobody cared. If that is stood up an= d we get tests, we'll have more data to know if it is wise to expand th= e experiment or close it down. In addition to being in line with tests in P= ython, this is in line with adapting risky technology that we've done i= n the past: We tried it out, kept what worked and junked what didn't. I= t's a risk for those wanting rust: it may be a failed experiment in whi= ch case their time is wasted. The hypothesis is that rust is useful and tha= t 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.</div><div>= <br></div><div>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 ho= oks in needed to use an external toolchain to build something. This is a wa= tered down version of write cvsupd, to be honest, but one that's testab= le, measurable, specific and finite. It gives us data for any follow on cho= ices.<br></div><div><br></div><div>Warner<br></div></div></div> --000000000000acf412060f7a0c63--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfo_MU4yo_4dvvTB%2BQf3JFT6EVEYZ4cmFHa%2BEJEjs_1crA>