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

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.

Softwares rewritten with Rust are increasing in ports, but I feel it's
not yet enough to get enough skilled persons with Rust for FreeBSD
community. Maybe it would be after language Rust itself and its ABI is
enough "stabilized".

And about "memory safety" aspect, google "Rust memory mapped I/O".
You would find a number of pages documenting how-to about it.
If language Rust forces "memory safety", noone can write device drivers
for which memory mapped I/O is required. It fundamentally needs
"volatile" memory region, and abusing the mechanism allowing it could
fundamentally mean "possibly unsafe".

In many places, I saw "Rust is for memory safety". So I thought Rust
cannot use for drivers requiring memory mapped I/O and/or DMA is
fundamentally impossible, but it seems to be somehow possible.
I'm very, very surprized about it.

No one can say "this software is memory safe, because it is fully
written in rust!".


> 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.

I remember that cvsup was finally rewritten with C as csup and imported
into base. ;-)

Regards.

> 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 ?
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.


-- 
Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>