Re: The Case for Rust (in any system)

On Wed, Sep 11, 2024 at 4:41 PM Chris <bsd-lists@bsdforge.com> wrote:
>
> On 2024-09-05 13:36, Alan Somers 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?
> >
> >>
> >> 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 don't think the problem is the language. C has proven to be an extremely
> powerful and capable language. If it were made impotent enough to prevent
> people from making mistakes. Would it be potent enough to do what needs to be
> done?
> IOW the people that use it are the problem. Not the language. Is *any*
> language
> that prevents one from shooting themselves in the foot powerful enough to be
> of any value? I say not. It will always be a matter of quality control, and
> until humans are made to be infallible. This will thread will continue.
> I know, I know, it's all philosophical, but still...

"Memory safety == restrictive training wheels" is just a common
misconception.  I've personally written 100k SLOC in Rust and I've
very rarely found anything that the compiler "won't let me do".  (TBH
It does very rarely happen, because of certain patterns that the
borrow checker doesn't understand, but the extra effort I've had to
spend to overcome those cases is dwarfed by the effort that I would've
expended to solve the same problems in C).  And if you *really* need
to break the rules, there's always the `unsafe` keyword.  If you've
never used a more modern systems programming language than C, then I
encourage you to try one out for a few months.  You won't regret it.

-Alan