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

On Sun, 04 Aug 2024 10:09:35 +0000
"Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:

> --------
> Konstantin Belousov writes:
> > On Sat, Aug 03, 2024 at 11:36:52AM -0600, Warner Losh wrote:
> > > [...]
> > > These are the things to think about. We don't need to solve all of
> > > them, but the Rust ecosystem is quite a bit different than the C ecosystem
> > > in the details of a number of these points, so we have to address them
> > > if we want to use Rust in base with the same traits as all the other bits
> > > in base today (or we need to have a thoughtful discussion on paradigm
> > > shift and settle on that). [...]
> >
> > [...]
> >
> > Instead of starting with integration into the build system, lets decide
> > which useful things can we implement in Rust.  Lets ignore the problems
> > of integrating (not yet written) code into the build, the problem of
> > crates that should be vendored, etc.
> 
> Stop.
> 
> Just Stop!
> 
> Let me address kib@'s argument first:
> 
> Until we recognize the difference between "a programming language" and
> "an ecosystem" these debates will lead nowhere.
> 
> If we continue ignore that crucial difference, we will be repeating
> our prior mistakes instead of learning from them.
> 
> Back in the mists of time we imported Perl into the base system,
> based on arguments /identical/ to what we hear now about Rust.
> 
> Importing Perl almost instantly turned into a disaster.
> 
> We had overlooked that Perl was not just a programming language,
> it was an ecosystem of a language /and/ an rapidly exploding number
> of Perl Modules from everybody and everywhere.
> 
> None of the lofty "We can (re)write all this stuff in Perl" promises
> came to anything, once people realized that we only imported Perl
> the programming language and not Perl the ecosystem (later known
> as CPAN).
> 
> Having Perl in the tree was a net loss, and a big loss, because it
> created a version gap between "real Perl" and "freebsd Perl", a gap
> which kept growing larger over time as enthusiam for Perl in the
> tree evaporated.
> 
> Adding Rust to FreeBSD will be the /exact/ same thing!
>
> The many differences between the Perl and Rust languages does not
> matter, the only thing which matters is that they are both ecosystems.

Although I've not yet popped into FreeBSD community at the moment, but
I'm old enough to see what happened with base perl in sync. So I can
understand what you feel. Me, too. This is why I intentionally and
explicitly put aside problems other than object format in my previous
post.

Introducing Rust ecosystem would force us (at last) to rewrite
everything possible into Rust and build/link just as usual Rust
programs does (build into single binary to maximize build time check
and computations to make Rust codes to be what Rust is).
I think it would be unacceptable.

I think introducing Rust ecosystem also requires introducing Rust
philosophy, which I "feel" in reverse of Unix philosophy.

Ideally, ISO/IEC nnnnn:yyyy "Programming language Rust" should be
proposed/discussed/approved and published before we actually start
introducing Rust "language" into FreeBSD base.

Frankly, I have no severe objection to introduce codes in Rust
"language" into base, if it is assured to be sanely linked with
existing codes and runs without harm.

And more, I don't want to see commit messages like "Rewritten
whole bunch of Rust codes because language spec of Rust is changed.".


> We can import only the Rust language, there is /no/ way we can
> import the Rust ecosystem.

Agreed, at least on current state.


> Any discussion and all promises about "useful things we can implement
> in Rust" must therefore respect the following explicit restriction:
> 
> 	You can only "use std::" and nothing else.
> 	(And probably not even all of std:: ?)
> 
> 
> That then brings me to Warner's point:
> 
> Because we cannot import the ecosystem, we have two options:
> 
> A) FreeBSD-Rust is only intended for use in freebsd-src, where
>    the Rust ecosystem will /never/ be available.
> 
> B) Make FreeBSD-Rust (seamlessly and continuously!) play nice with
>    both Rust in ports and the Rust ecosystem outside ports.
> 
> I have no idea if B) is even possible or what it would take, but
> without a design, implementation /and/ continuous maintenance of
> B) we (eventually) get A).
> 
> In-tree-Perl was not (well-)integrated with ports, which I recall
> not so much as caused by technical limitation as by the users wanting
> the latest and greatest Perl, rather than the out-of-date FreeBSD-Perl.
> 
> I expect that outcome for /any/ programming language ecosystem[1].
> 
> Assuming B) is even possible, and attempted, it is almost guaranteed
> to be a waste of our time and energy, and it will fizzle back to
> A) in a couple of years.
> 
> The alternative to spending time on A) for a modest likely benefit,
> is to work towards a pkg-based distribution of FreeBSD, where nobody
> notices, or cares, that some of the pkg's are built out of src and
> others are built out of ports, with the benefit of the Rust ecosystem.

There could be option C).

C) Keep Rust itself as external toolchain maintained in ports framework,
   regardless how important and mandatory the Rust codes in base are.
   But restrict in-base Rust codes not to use external crates and use
   standard and vendor-imported ones as contrib. Allow external (usual)
   crates only for ports.

Ah, maybe one more restriction could be useful.
Prohibit use of "UNSAFE" blocks in base Rust codes, and keep such
memory-unsafe portions of codes in *.c and *.S then link with them.
It would ease debugging memory-safety related problems, as (if Rust
works as Rust guys state) we not at all required to look into *.rs
codes. If "UNSAFE" blocks are not prohibited, we would be forced to
look into *.rs codes, too, in such a situations.


> 
> ... or built out of C++ modules.
> 
> ... or written in Python.
> 
> ... or ...
> 
> Poul-Henning
> 
> -- 
> 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>