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

On Sun, 21 Jan 2024 07:51:32 +0000
"Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote:

> --------
> Ihor Antonov writes:
> 
> > As much as I love the idea of Rust, I don't think it is going to
> > solve our problems.  
> 
> The tools are /never/ the real problem.
> 
> I will readily agree that the ISO-C people have done more to hurt
> the C language, and less to improve it, than anybody else, and that
> we need to deal with their continued refusal to come into the
> 1990'ies.

I would love for you to expound on this point further.

> But after I read this entire thread, the "pro" argument for Rust
> seems boil down to just "all the cool kids do it".
> 
> That exact same argument was used for "Perl in base" and "Java in
> base" previously, and if we hadn't dodged those bullets, we wouldn't
> be here today.
> 
> The sprawling and loosely connected ports collection has several
> strata of "all the cool kids do it" languages, and it seems to be
> a much better "organism" for dealing with their eventual obsolescence,
> than our tightly integrated src collection.
> 
> I will also "second" the comment about C++ getting to be a really
> good language, in particular if you play it like a violin:
> 
> 	Just because you /paid/ for the entire bow, doesn't mean you
> 	have to /play/ the entire bow.

Unfortunately, most Rust programmers treat cargo and crates.io the same
way most C++ programmers treat the Standard Template Library and
Object Oriented Programming. As much, as many, and as often as
possible.

 
> So rather than jump onto this or some other hypewagon-of-the-year,
> only to regret it some years later and having to repay the technical
> debt with interest to get it out of the tree again, I propose that
> we quietly and gradually look more and more to C++ for our "advanced
> needs".

I don't have your programming experience in and familiarity with C++ so
I am looking at this from a different angle. I am worried we might end
up with more technical debt faster if we use C++ than if we try
something else. In my experience with Linux, now FreeBSD, and college
I have seen more C++ and Java projects eat their original programmers
out of the project and die than any other two languages singularly or
combined. Even the "unmaintainable" C projects I have tried to
resurrect got further than any attempt at resurrecting less decayed
Java or C++ projects. I don't know exactly why but I have my
suspicions. Based on those suspicions I am very leery of migrating code
to C++.

Rustc and/or Cargo will not be fun to integrate into the build system
for base. I think that integration and the Rust code it supports will
be easier to maintain or replace than any C++ code.

I can mechanically substitute another repo for crates.io which will
block Cargo from pulling in anything we don't curate. I don't know of a
way to enforce a subset of C++.

> I also propose, that next time somebody advocates for importing
> some "all the cool kids are doing it language" or other, we refuse
> to even look at their proposal, until they have proven their skill
> in, and dedication to, the language, by faithfully reimplementing
> cvsup in it, and documented how and why it is a better language for
> that, than Modula-3 was.
>
> Poul-Henning
> 

How do you define all the cool kids are doing it language versus I am
assuming a serious language? I am not being sarcastic. For example I
would personally call JavaScript unsuitable for operating system
components but there is a huge amount of it out there. Darcs is written
in Haskell but I don't think Haskell is good for operating system
components.