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

Wow, there have been a lot of responses.  I think I touched on a
sensitive issue.  I'll group everything together in one reply.  TLDR;
I think imp's proposal is best.

* Rust's ABI is too unstable to use for libraries

This actually isn't a problem.  The stability situation for the Rust ABI is
similar to C++; you can't link a C++ app to a C++ library unless they were both
built with the same compiler version.  The C ABI, of course, is quite stable.
And it's very easy to build a Rust library as a cdylib so that C applications
can access it.  But there are restrictions: the library's public API can't do
things that C can't, like generic functions.

* Why Rust instead of Perl, Java, C#, or Go?

The crucial difference between Rust and those other four, basically between
Rust and everything else since C++ [1], is that Rust is suitable for low-level
systems programming.  It lacks memory manangement, green threads, etc.  The
runtime is small (and optionally can be removed entirely).  Rust isn't quite as
low-level as C, but it's in about the same position as C++.

* Why not just use C++ then?

Speaking from experience, I'm far more productive in Rust than C++, and my code
has many fewer bugs, too.  I had been using C++ professionally for 11 years
before I learned about Rust, but after 6 months my Rust skills were better than
my C++ skills.  That's why I finally realized that I wasn't the cause of my C++
problems; C++ was.  In general, it feels like C++ has a cumbersome mix of
low-level and high-level features. Smart pointers, for example, are handy.  But
because it retains so much C-compatibility C++ can't enforce the use of smart
pointers.  And it can't even warn against the use of dumb pointers.  It
certainly can't check their lifetimes.  But in Rust, all pointers are smart
[2], so the compiler can help you avoid a wide range of common bugs.

* Rust will go out of fashion by the 2040s

Perhaps it will.  But Like David Chisnall, I'm afraid that if FreeBSD never
modernizes, then it itself will go out of fashion by the 2040s.

* "<something> can't be implemented unless written in rust"

I don't think anybody has claimed this yet.  But I _have_ made a similar claim,
that some things can't be written in C.  I'll elaborate on the project that
started this thread: the fusefs test suite.  When I designed the fusefs test
suite, I based it around the priniciple of Mocking.  Each test case has a client
thread that does normal file system access, and a server thread that implements
a fuse file server.  But it isn't a full implementation of a fuse file server;
it's just a shim around a mock object.  For each test case, the file server's
behavior is programmed with expectations.  The mocking technique is so limited
and awkward to use in C that almost nobody bothers.  Just compare the
documentation for CMockery (C) with Mockall (Rust).  C++'s Googlemock is
somewhere in between.

* async Rust sucks

I disagree, but that's probably worth a separate email thread of its own.  In
particular, some of the content on the linked rant is not accurate.

* Reimplement CVSUp in Rust

That sounds like a challenge!  I'm not saying that I want to do it, but I'm
still interested to look at how CVSUp was done.  But where is it?  The port is
deleted and the web page is gone.

* Rust in base would double our compile times

Yes, it would.  That's the worst thing about it.

* Rust in base would cause massive code bloat.

Yes, it would, because in addition to the toolchain and standard library most
Rust applications would pull in various dependencies.  Command line argument
parsing, serialization/deserialization, fancy data structures, etc.  For both
this and the above reason, I'm really liking imp's proposal for a "make
extraworld" - stuff that's in base but depends on an external toolchain.

[1] Yes I know about Modula-3, D, etc.  But for various reasons those
never gained traction.
[2] Dumb pointers exist too, but they're almost never used except when
binding to a C library.
[3] https://github.com/lpabon/cmockery2/blob/master/doc/usage.md
[4] https://docs.rs/mockall/latest/mockall/