Date: Thu, 5 Sep 2024 19:39:24 -0600 From: Warner Losh <imp@bsdimp.com> To: Alan Somers <asomers@freebsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: The Case for Rust (in any system) Message-ID: <CANCZdfoFgMshcLL1MF060YxVUvsE3S09XDNrT0GiosCreeN5RQ@mail.gmail.com> In-Reply-To: <CAOtMX2hY22v6w5coXSVEtoKWfJTYY-ML6zt-fUf=R6upc-bvgQ@mail.gmail.com> References: <CAOtMX2iCNX5OkdeghnbmcMrO0UYWwm4zfxFSZGznOznu%2Bmh5rA@mail.gmail.com> <CANCZdfoHP3G3YMvpqVwpQZSRQ64pnYhBJD60Dcar%2BBCUaJNL-w@mail.gmail.com> <CAOtMX2hY22v6w5coXSVEtoKWfJTYY-ML6zt-fUf=R6upc-bvgQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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 [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 5, 2024 at 2:36 PM Alan Somers <<a href="mailto:asomers@freebsd.org">asomers@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Sep 5, 2024 at 2:16 PM Warner Losh <<a href="mailto:imp@bsdimp.com" target="_blank">imp@bsdimp.com</a>> wrote:<br> ><br> ><br> ><br> > On Thu, Sep 5, 2024 at 12:10 PM Alan Somers <<a href="mailto:asomers@freebsd.org" target="_blank">asomers@freebsd.org</a>> wrote:<br> >><br> >> By now I expect that most of you have seen the long list of new<br> >> security advisories that just came out. Strikingly, all were the<br> >> result of memory handling errors. And none of them wouldn't have<br> >> happened if their respective programs had been written in a<br> >> memory-safe language.<br> ><br> ><br> > FreeBSD represents hundreds of thousands or millions of man hours<br> > in its current form (depending on how you measure it). It has evolved<br> > over 30 years. To get to the same level of maturity in a rust rewrite would<br> > take a similar amount of time. But even if it took an order of magnitude<br> > less because rust is that much better, that represents a huge pool of<br> > manpower that don't seem to be hanging out around the project just<br> > waiting for something to do.<br> <br> Sure. I for one am not volunteering to rewrite CTL next week.<br> <br> ><br> > Where do the resources for this come from? Without enough resources,<br> > the rewrites will be crap and nobody will want to use them (or maybe even<br> > FreeBSD). The rewrites to date have lost functionality (though maybe not<br> > functionality that's important) relative to what they replace.<br> <br> Which rewrites are you thinking of?<br></blockquote><div><br></div><div>rs-gstat differs in a number of ways from gstat, including writing ANSI codes</div><div>directly (at least in the version I looked at) rather than using curses. It's a little</div><div>thing, and it might not really matter.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> ><br> > So great, we should switch to rust. But so far we have no way to do that<br> > incrementally (other than a parallel build system, which isn't very FreeBSDish).<br> > And if we can't even find the resources to do that minimal level of work, how<br> > can the rest possibly be robustly undertaken?<br> ><br> > Warner<br> <br> Your point is obvious; FreeBSD is too big to rewrite the whole thing.<br> But my point stands: new projects (whether inside of FreeBSD or not)<br> should almost always be using a safe language. And any component that<br> needs a major overhaul anyway should probably also be written in a<br> safe language, too.<br></blockquote><div><br></div><div>I tend to agree with that. New, large products should be written in the most</div><div>appropriate language for their problem domain. We'll have a lot of legacy C</div><div>code for a long time, though... I'm not entirely convinced it has to be a safe</div><div>language, however, but that's more about practical considerations than</div><div>whether it would be better...</div><div><br></div><div>Warner</div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoFgMshcLL1MF060YxVUvsE3S09XDNrT0GiosCreeN5RQ>