Re: The Case for Rust (in any system)

On Thu, Sep 5, 2024 at 2:36 PM Alan Somers <asomers@freebsd.org> wrote:

> On Thu, Sep 5, 2024 at 2:16 PM Warner Losh <imp@bsdimp.com> wrote:
> >
> >
> >
> > On Thu, Sep 5, 2024 at 12:10 PM Alan Somers <asomers@freebsd.org> wrote:
> >>
> >> By now I expect that most of you have seen the long list of new
> >> security advisories that just came out.  Strikingly, all were the
> >> result of memory handling errors.  And none of them wouldn't have
> >> happened if their respective programs had been written in a
> >> memory-safe language.
> >
> >
> > FreeBSD represents hundreds of thousands or millions of man hours
> > in its current form (depending on how you measure it). It has evolved
> > over 30 years. To get to the same level of maturity in a rust rewrite
> would
> > take a similar amount of time. But even if it took an order of magnitude
> > less because rust is that much better, that represents a huge pool of
> > manpower that don't seem to be hanging out around the project just
> > waiting for something to do.
>
> Sure.  I for one am not volunteering to rewrite CTL next week.
>
> >
> > Where do the resources for this come from? Without enough resources,
> > the rewrites will be crap and nobody will want to use them (or maybe even
> > FreeBSD). The rewrites to date have lost functionality (though maybe not
> > functionality that's important) relative to what they replace.
>
> Which rewrites are you thinking of?
>

rs-gstat differs in a number of ways from gstat, including writing ANSI
codes
directly (at least in the version I looked at) rather than using curses.
It's a little
thing, and it might not really matter.


> >
> > So great, we should switch to rust. But so far we have no way to do that
> > incrementally (other than a parallel build system, which isn't very
> FreeBSDish).
> > And if we can't even find the resources to do that minimal level of
> work, how
> > can the rest possibly be robustly undertaken?
> >
> > Warner
>
> Your point is obvious; FreeBSD is too big to rewrite the whole thing.
> But my point stands: new projects (whether inside of FreeBSD or not)
> should almost always be using a safe language.  And any component that
> needs a major overhaul anyway should probably also be written in a
> safe language, too.
>

I tend to agree with that. New, large products should be written in the most
appropriate language for their problem domain. We'll have a lot of legacy C
code for a long time, though... I'm not entirely convinced it has to be a
safe
language, however, but that's more about practical considerations than
whether it would be better...

Warner