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

In message <2f38cbcd-61a9-42b7-b7e6-ebd261fe66da@FreeBSD.org>, Matthias 
Andree
writes:
> Am 21.01.24 um 11:24 schrieb Bertrand Petit:
>
> > 	One of the strong values of FreeBSD is its stability. For fun I
> > recently booted a 4BSD-something on a VAX emulator and immediately felt at
> > ease, because of this stability. I perceive rust, despite some of its
> > technical merits, as unable to provide that kind of stability. This languag
> e
> > is a fast and (still) unstable moving target, so fast that once integrated 
> it
> > will immediately be obsolete on release. The integrated version would proba
> bly
> > only be usable to compile base, countless other packaged versions would be
> > required to compile ports---I'm also thinking about llvm here. That is boun
> d
> > to be a maintenance nightmare, for the FreeBSD teams and for the users alik
> e.
>
> I have read this thread up to what's here now, and I like that it kept 
> to a very useful constructive tone and arguments exchanged.
>
> So, personally, I've always found a language whose compiler gets 
> recompiled several times a week if I do ports development is something I 
> definitely can't advocate having in source.
>
> The same goes for the 3rd party stuff.
>
> Even if you mirror external dependencies to prevent from losing them 
> with some upstream maintainer's decision, and keep maintainable, that 
> begs the question: who is reviewing, polishing, maintaining this?  We 
> certainly don't want Log4J-like disasters to strike because in all 
> convenience and "don't rewrite the world" programmer-time efficiency 
> claims we used all sorts of, whoever wrote this, "half the Internet".
>
> I understand that people who have spoken up in this thread have 
> inter-individually mixed feelings (meaning one person proposes it, the 
> next person is loathe of it) about C++, about the Standard Template 
> Library (STL) in particular, and I find it a pity that most arguments in 
> this thread around C++ did not mention a standard edition's year.
>
> I have been around C++ since before it became an ISO standard, I have 
> seen it on the decline when C++03 seemed to have stalled, but I can 
> really sympathize with Microsoft's "Welcome back to C++" approach.  C++ 
> has come a really long way, and over the past decade shown to deliver 
> continually. C++14 or C++17 is lightyears ahead over what people left 
> behind who haven't followed/used it in many years.
>
> So I really would have wished for people to not just write C++ but 
> really the minimum/oldest edition they would consider.
>
> I understand why people sometimes steer clear of Standard Template 
> Library - but I really liked how clear the dis-/advantages of its 
> datatypes and algorithms are laid out.  Yes, you can still shoot holes 
> into your extremities when abusing the language, but Rust also has 
> unsafe modes...
>
> Rust advocates usually write about safety, but do we really want to 
> argue about introducing all this technical debt to just rule out ONE 
> PARTICULAR class of errors when there are dozens of others that open up 
> security risks?   Seems a bit drastic to me.
>
> Do Rust proponents audit what all the indirect dependencies' codes do 
> before referencing them?  Or are there bodies that tell us what 
> libraries are safe, when the base language can't dance?
>
> So bottom line, let's see to pushing Rust back and keeping it out of the 
> base system until it is stable, mature, and useful without betting and 
> risking our world on half of the outside Internet -- and we really know 
> it's not just another fad of the decade and have valid use cases that 
> really can't be shown in what we have in the base system today.

I've been following this as well and I think the above summarizes my 
opinion as well. Linus Torvalds had stated he was cautiously optimistic 
about using Rust in the Linux kernel before it was allowed into Linux 6.1. 
Reading what imp@ has said in this thread, I tend to get the same message 
from him.

I'm not enamoured with crates. kib@ touched on this. And this is one of my 
sticking points WRT Rust (for a long time).

Calling it as an external toolchain tool would cause a lot less churn for 
now until we can settle on a specific version. However the language is 
evolving at a rapid pace, like Perl and Python have (and still are). 
Importing Rust and allowing it to accumulate bitrot vs. maintaining it at 
its current level each have significant disadvantages while addressing 
issues the other creates.

Adding Rust code to base and relying on an external toolchain compiler will 
also cause some, though not as much, churn because existing code will need 
to evolve with the compiler. Take Firefox as an example. Try building it 
with an older Rust compiler. It won't work. Furthermore, there was debate a 
the last Linux Maintainers Summit in 2023 about the issue of compiler 
versions. And according to https://www.zdnet.com/article/linus-torvalds-rust
-will-go-into-linux-6-1/, there were concerns about non-standard Rust 
extensions needed in the Linux kernel to get it to work in Linux.

WRT Linux userland, the various distros are each doing their own thing.

This is certainly requires more objective reflection before we jump all 
into Rust.

>
> -- 
> Matthias Andree
> FreeBSD ports committer, speaking his personal opinion
>
>


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e^(i*pi)+1=0