Date: Tue, 06 Aug 2024 00:46:51 +0200 From: Steffen Nurpmeso <steffen@sdaoden.eu> To: Warner Losh <imp@bsdimp.com> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Cy Schubert <Cy.Schubert@cschubert.com>, freebsd-hackers@freebsd.org, Bakul Shah <bakul@iitbombay.org> Subject: Re: The Case for Rust (in the base system) Message-ID: <20240805224651.sDOyBurF@steffen%sdaoden.eu> In-Reply-To: <CANCZdfpB9k_gzuLUij-kuwXMeMDqVwfx9DUsWBdmwNEtMvVkaA@mail.gmail.com> References: <CAOtMX2hAUiWdGPtpaCJLPZB%2Bj2yzNw5DSjUmkwTi%2B%2BmyemehCA@mail.gmail.com> <vdmg5zocd6wqcwc2bvzvzqn4bii2pwdc2r4mgnisukfkboj6nf@f7lv5quu4fjx> <CAOtMX2iDK3uN_oQgzzZAdoOZCfNsnvpefeZvKoTCRmPBhZywzA@mail.gmail.com> <CANCZdfqB1%2B-8BkpKwKoCM%2BzM4mCOFy63yHr1Pco7MnT1DFkb4w@mail.gmail.com> <EF084C36-D2EA-4194-B30F-253B0E8D5B4D@iitbombay.org> <704D020F-78A4-4926-AE3C-41F7FD619A89@cschubert.com> <20240805210149.nrkHN3j3@steffen%sdaoden.eu> <202408052127.475LROnE067608@critter.freebsd.dk> <CANCZdfrh-74M0L-Z%2BOOnqSD6xO3PyaUXWc8LPWxtRbsWawu4qA@mail.gmail.com> <202408052206.475M6h8E067967@critter.freebsd.dk> <CANCZdfpB9k_gzuLUij-kuwXMeMDqVwfx9DUsWBdmwNEtMvVkaA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote in <CANCZdfpB9k_gzuLUij-kuwXMeMDqVwfx9DUsWBdmwNEtMvVkaA@mail.gmail.com>: |On Mon, Aug 5, 2024 at 4:06=E2=80=AFPM 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. That sounds nothing but good. (I was not really serious at first btw.) =20 |Having said all that, I'd love to see us be able to make better of rust a= nd |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. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | | Only during dog days: | On the 81st anniversary of the Goebbel's Sportpalast speech | von der Leyen gave an overlong hypocritical inauguration one. | The brew's essence of our civilizing advancement seems o be: | Total war - shortest war -> Permanent war - everlasting war
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240805224651.sDOyBurF>