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

From: Baptiste Daroussin <bapt_at_freebsd.org>
Date: Tue, 23 Jan 2024 07:48:08 UTC
On Mon, Jan 22, 2024 at 05:33:44PM -0600, Robert R. Russell wrote:
> On Mon, 22 Jan 2024 08:57:47 +0000
> "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:
> 
> > Robert R. Russell writes:
> > 
> > > How do you define all the cool kids are doing it language versus I
> > > am assuming a serious language? I am not being sarcastic.   
> > 
> > That is a fair and valid question.
> > 
> > My comment was not so much about the language itself, as about the
> > arguments tendered for why we should import it in FreeBSD.
> > 
> > Let me fold that out, so we have it in the mail-archive for future
> > use:
> > 
> > Rust has certainly been around for long enough to be taken seriously,
> > but so has FORTH, C++, Perl, Tcl, Modula-3, Haskell and Lua, all
> > of which have at one time or another, tried to wiggle their way
> > into FreeBSD-src, with very different outcomes.
> > 
> > FORTH is still here, because the loader uses it.  The loader used
> > to be incredibly size-constrained, so FORTH was almost the only
> > option we had, but that is much less of an issue now, and Lua is
> > eating into the loader, because one can actually read Lua code.  (I
> > personally love FORTH, but RPN is not for everybody.)
> > 
> > C++ is still here.  It got in because it sort-of came for free
> > with GCC and we needed it for groff to read our manual pages.
> > These days groff is gone, but now CLANG uses C++, so it stays.
> > The maintenance load is very small compared to the load carried.
> > 
> > Perl got in, and got thrown out again, when we saw how much pain
> > it caused.  Partly because the situation with perl-modules where
> > very similar to what people say about Rust crates, but also because
> > the language was so rapidly evolving, that we would never be able
> > to ship an acceptably up to date version in our releases.
> > 
> > As I remember it, Tcl never got in, despite me pushing heavily for
> > it, and today I will agree that Lua does the "embedded language"
> > thing much better.
> > 
> > Modula-3 had one thing going for it:  CVSUP, but even though that
> > was for the project what git(1) is for us today, that wasn't enough.
> > In fairness I should say that the maintenance would have been very
> > heavy because of the posix-incompatible threading.
> > 
> > Haskell barely got any discussion, as I remember it, the arguments
> > were nowhere near credible.
> > 
> > Lua had a strong use-case, came with a good proof-of-concept code and
> > a very small maintenance footprint.  You literally cannot tell that
> > it isn't just "another library".
> > 
> > To me Rust lands somewhere in the cursed triangle between C++, Perl
> > and Modula-3.
> > 
> > Rust's rapid release-cycle means that we will have to deliver the
> > built-in Rust in such away that the users can install a newer Rust
> > from ports, or directly, without friction.
> > 
> > As far as I can tell, Rust is no better prepared for that than Perl
> > was, and the Rust Crates equally not so, like the Perl Modules.  At
> > the very least, that means serious maintenance work for us, and we
> > will probably still annoy the actual users of Rust.
> > 
> > With Perl we ended up have a special magic "only for use in the
> > tree" Perl, and if people wanted to use Perl in any other way, they
> > had to install another Perl from ports.
> > 
> > Then there is the "There's always a Crate for that..." attitude,
> > which we also saw with Perl:  We received numerous "Perl in base
> > is useless unless we also import at least the following N Perl
> > Modules" for a very large union of Ns.
> > 
> > Fundamentally there is a huge difference between importing a
> > programming language, which we have done successfully, and importing
> > an eco-system, which we tried once and ran screaming back.
> > 
> > Even ports, which is laser-focused on 3rd-party software, is having
> > some impedance trouble with eco-systems.
> > 
> > But it could still make sense for us, if we decide to go all-in,
> > the way for instance Mozilla has chosen to do:  If most of userland
> > ended up being Rust programs, the amortized maintenance hazzle might
> > be worth it.
> > 
> > But I dont see that happening: The testing and validation that we
> > got all (mis-)features to be (bug-)compatible would be an utter
> > waste of time, and who would care if paste(1) is written in C or
> > Rust anyway ?
> > 
> > If we do not go all-in, Rust needs a "killer-application", and
> > as you have probably spotted already, my "rewrite CVSUP" was not
> > just a flippant thought:  If CVSUP was not enought to get Modula-3
> > over the line, Rust will have to do better.
> > 
> > If people want Rust in FreeBSD, their first task is to show, with
> > actual code, how much better it would make FreeBSD, and I saw nothing
> > like that in the email thread, and thus the "all the cool kids use
> > it" summary.
> > 
> > I know that we in the Varnish project love our "varnishtest" to
> > pieces, it has made us so much more productive, but I dont know
> > if a "freebsdtest" program, written in Rust or any other language,
> > would become the same kind of success.
> > 
> > Poul-Henning
> > 
> > PS: And to take this to it's logical conclusion:  Apart from
> > tradition, I'm not sure I see why we have a C-compiler in the tree
> > anymore.  Wouldn't everybody's life be easier if we just used
> > a compiler from ports ?
> > 
> 
> First thank you for the reasoned response. Second the project probably
> needs a discussion about the build system and can the compiler be moved
> to ports. I think that is off topic for this thread.
> 
> Looking back at my own Rust code, We appear have come to similar
> conclusions about Crates.io value. SERDE in particular has become one
> dependency I try to avoid at all cost.
> 
> Which I think leads to one of my big reasons for supporting Rust and
> something else that needs to be moved to its own thread, Text encoding
> issues. I think the project needs to follow OpenBSD's lead and
> deprecate non UTF-8 locales. While I personally can't read or write
> anything other than English and a few dozen words in Spanish,
> Portuguese, and French, I can find or create test input data that isn't
> in basic ASCII and test my string handling against such input. Assuming
> allowing things like French column names make sense.

First this is already deprecated, only utf-8 locales and encoding are being
updated on regular basis! Second, no we will not follow the path of OpenBSD here
because locales are not only for interactive, but text processing, like
for example databases (collation, comparison etc) and there are plenty of data
stored that cannot be converted to unicode for many valid reason, dropping non
unicode locales will just make sure those data and databases cannot be served
on FreeBSD anymore! (btw note that OpenBSD, while having deprecated all non UTF-8
encoding support, do not support unicode collation).

Best regards,
Bapt