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

On Mon, Aug 5, 2024 at 4:06 PM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> --------
> Warner Losh writes:
>
> > > > Most user space tools could be written in lua.
> > >
> > > That /exact/ same argument was made for Perl :-)
> >
> > Lua's been in the base since I imported it for the boot loader, though...
>
> Lua is is much more "language" than "eco-system", by design as I
> understand it, so that is a different situation than Perl or Rust.
>

Indeed. The standard stuff is fairly small, and we're doing it all as
a 'private' library, so ports will never see what we pull in.

I personally do not subscribe to to the "let's rewrite all the 50
> year old source code to make it more safe" philosophy, but there
> are valid arguments when the old code is horrible.
>

Plus we're writing new stuff only, and typically only where it makes
a lot of sense (lots of string processing). Plus we're keeping the scripts
as compatible with what little ecosystem there is so we can go back
and forth between the ports lua and the base flua.


> But there are some wrinkles.
>
> First: Anything setuid/setgid is off-limits.
>
> There are good reasons why we dont have setuid shell-scripts (any more!)
>
> I guess with most systems being effectively single-user these days,
> that may not be as much a security focus as it was back in the 1990ies.
>

Yea. No plans there.


> Second: Performance.
>
> I cannot remember the exact subset of bin programs somebody did in
> Perl as proof of concept, but it slowed down buildworld a LOT to
> fire up all of Perl to do trivial stuff like "echo", "chown" and
> "mkdir".
>
> Lua may be cheaper than Perl, but it will still be measurable.
>

Yea. I'm guessing you wouldn't notice, but why do that. There's
no benefit and only a myriad of ways to introduce new bugs
or non-posix conformance where we were conformant before.

I'm definitely in the "why are we rewriting stuff in rust" because
it doesn't move the ball forward, really. At best it's a great leap
sideways,
maybe with marginally better actual safety. At worst, it's a great leap into
a morass of almost compatible that causes great grief in the gaps, or
worse, has new security problems the old one didn't. So rewriting
for the sake of rewriting seems like a giant waste of resources.
Rewriting strategically to fix areas that have had safey issues
may be different, but cp.rst isn't going to be any better, than
cp.c in most aspects because cp.c has had 50 years to be
debugged.  And 50 years makes up for a lot of danger
in the language.... So there may be things that we get some
advantage out of by doing a rewrite in rust, but I'm in the
'case by case basis' camp there: those cases where the cost / benefit
ratio is favorable should be considered. But they can't be
considered entirely in a vacuum because there's a non-zero
cost to rust in the base, even as an external toolchain.

Having said all that, I'd love to see us be able to make better of rust and
new rust programs where it makes sense. That's why I've been
encouraging people to give it a go to show us the money. To
show up that we can integrate it (even if it is just a few lines in
Makefile.inc1 that builds everything, optionally, as part of
buildworld). That shows us we can keep the dependency hell
under control, that we can update things sanely (more ecosystem
here, not language). How much work is it to track the latest versions,
how do we deal with that as the number of new rust programs grow,
how do we deal with ABI stability, etc. And to show us if there's an
actual advantage to all of that over what we can do in ports, or what
we might do with pkgbase somehow. I'm unsure of the outcome of all
this, but I think it would be wrong to shout it down completely. To do
all that, people need room to experiment and show what's what.

Warner