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

On 1/20/24 14:31, Warner Losh wrote: ...

As someone who's been writing rust since 2018 both professionally and for
personal projects I want to share my perspective on the question.

I've come full circle from being a zealous rust fan-boi and now back to 
being a
careful skeptic. There is a lot of ground I want to cover in one email so I
excuse my style, I will be happy to elaborate and provide more data to 
back up
my statements.

Rust in base
------------

I think the consensus in this thread has already reached the right 
conclusion.
This would be a absolutely counter-productive for the following reasons:

- Rust needs its own special brand of LLVM. We all know how long it 
takes to build.

- Rust compiler is not usable without Cargo, and Cargo is a 
fast-evolving project
   that will need constant upkeep.

- There is no way to bootstrap rust compiler other than by using previous
   version of their compiler. Effectively you start from a blob from a third
   party that you need tp trust. This can be a huge problem for people 
who care
   about supply chain security. C/C++ compilers can be bootstrapped in a 
reasonable
   amount of steps almost from nothing (google GNU Mes, stage0)

- Rust and its entire ecosystem has severe dependency bloat problem. It is a
   'left-pad' minefield. For those who want proof take a look at 
Cargo.toml files
   of Cargo and rustc projects - they depend of half of the Internet. 
Getting
   a closed-loop self-sufficient set of crates is almost impossible. 
Rust compiler
   is not self-hosting and its dependency set has unbounded growth problems.

- There could also be legal problems, as Rust Foundation is not a very 
adequate
   or mature entity. Not so long ago they were trying to ban all 
"unapproved mentions
   of the word Rust", waving their trademark left and right.
   Search for "rust drama" on the internet  to find more details.


Rust in General
---------------

Rust's ecosystem is infected with async, aka. function coloring problem.
It creates so much more pain that writing rust becomes nearly impossible.
But hype-driven crowd has not yet realized it. Read more [2]


Rust in Ports
-------------

Something like mentioned `freebsd-rust` separate repository could make 
sense,
with careful crate curation to maintain self-sustaining offline-build 
capable
set. And avoid async rust at all costs.

The question here - what is the "contract" here?  I dont think we are ready
to force Rust on every FreeBSD src consumer.


Alternatives
------------

I never thought I would ever say this - but C++20/23 is actually not 
that bad.
C++20 modules are finally here and they actually solve header problems. 
Linux
kernel developers were discussing C++ last week here [1] for use in Linux
kernel. Lots of good reasons expressed.

Replying to Warner's comment:

 > We have had C++ in base for many years, but I don’t see any good 
libraries
 > for CLI, logging, JSON, etc.

Despite being full time FreeBSD user since 2017 I didn't know we needed 
those
(and I am happy to contribute) I will say that this is not a C/C++ 
problem and
Rust is definitely not a solution It is a FreeBSD problem and there are 2
aspects to it:

1. Social Aspect - we have a problem with attracting contributors:

     1.1. A path to becoming a src contributor is vage and unreasonably 
long.
     1.2. Unclear project directions(from a newcomers perspective)
          Is FreeBSD a stagnation cult? Do we want to re-implement every 
linux feature?
          Were does the Project go? Who is in charge? How decisions are 
made?
     1.3 Unclear who needs what. It is the first time I hear Allan needs 
help with
         writing code. (Allan - expect a dm to discuss details, I'm 
happy to help)

2. Technical Aspect

     2.1. FreeBSD has tooling problem: bespoke BSD Makefiles are not 
making it easy
          to start a new project or port new code. IMHO we need to 
import Ninja and Cmake
          into base to make it easy write and _test_ more C/C++ code.

          Phabricator forces everyone to have PHP. Bugzilla is a 
retro-vomit from 2000,
          Jenkins is a devops nightmare from hell (speaking from a 
decade of personal experience)

     2.1. FreeBSD has information fragmentation problem: Where was that 
piece of information?
          A PR on github? Review on Phab? Maybe it is in the wiki?
          Check the handbook to be sure. Oh, right, it was that patch 
attached to a bugzilla
          comment. Go check Jenkins if the latest *post* commit run as 
succeeded...


Summary
========

As much as I love the idea of Rust, I don't think it is going to solve 
our problems.
Rust is hype tech at the moment and 2 years down the road compaines will 
start to realize
how much maintenance of async rust code actually costs.

I would very much like to see us simplify contribution track.
On the technical side - migrate off of phabricator to gitea and import 
cmake and ninja.
Kill bugzilla and build a decent pre-commit CI.

---------
[1] 
https://lore.kernel.org/lkml/3465e0c6-f5b2-4c42-95eb-29361481f805@zytor.com/#t
[2] https://blog.hugpoint.tech/avoid_async_rust.html


Ihor Antonov

-- 
Ihor Antonov