Speculative: Rust for base system components

[Cy Schubert]

In message <a2d04773-c7cc-457d-4db6-913cb84e885b at metricspace.net>, Eric 
McCorkl
e writes:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --tu7wwqLaLNvV59iK66RVuCN4u9LNuo2ra
> Content-Type: multipart/mixed; boundary="40zQJvQINjrS8i7U0w9C4z0duC53dUJgc";
>  protected-headers="v1"
> From: Eric McCorkle <eric at metricspace.net>
> To: freebsd-hackers at freebsd.org
> Message-ID: <a2d04773-c7cc-457d-4db6-913cb84e885b at metricspace.net>
> Subject: Re: Speculative: Rust for base system components
> References: <20190101045638.D280E1F56 at spqr.komquats.com>
> In-Reply-To: <20190101045638.D280E1F56 at spqr.komquats.com>
>
> --40zQJvQINjrS8i7U0w9C4z0duC53dUJgc
> Content-Type: text/plain; charset=utf-8
> Content-Language: en-US
> Content-Transfer-Encoding: quoted-printable
>
> On 12/31/18 11:56 PM, Cy Schubert wrote:
> > What would having another language in base buy us? This reminds me of a=
>  couple of months ago at OpenHack Victoria someone was trying to convince=
>  me that the kernel needed a JavaVM. (Sure we each had a few beers) but t=
> he similarity of this discussion doesn't escape me. Kernel modules and fu=
> nctions written in java^H^H^H^H rust: why?
>
> I don't think that's a fair comparison at all.  Rust is a systems
> language built around zero-cost abstractions that is usable for
> developing real embedded code.  Java is a completely different animal,
> and there is no reasonable case for a Java VM in the kernel/loader.

What is the proposal then? Just to have another language in base? If 
it's just that, wouldn't the port suffice?

>
> I'm all for discussion and criticism of this, that's why I posted it,
> but I don't think these kinds of false equivalences are helpful.

Actually it is helpful. Without a solid proposal of a new feature or 
userland utility to be imported into base that requires the support of 
a language not already in base, the implication of the original email 
starting this thread was to rewrite FreeBSD using rust. There is 
equivalence as the argument that evening was, "there are more Java 
developers than C developers and replacing C with Java would benefit by 
adding to the pool of possible contributors."

In reality we should rely more on ports. Over the years this business 
has become more fragmented. Each year we see new languages being 
developed and used. Importing new shiny objects into base is 
unsustainable. IMO the momentum is behind containerization, 
specifically kubernetes and docker-like containers. That is today. The 
next year or two will introduce new technologies and shiny objects 
which we will likely need to introduce here to remain relevant. We 
should be looking to reduce the footprint of base, introduce new 
technologies in ports (ports are much easier to build from scratch, 
maintain, and update than base). Additionally the idea of meta-ports 
that install groups of packages would make building purpose-built 
systems a breeze for our user base, similar to what anaconda does, like 
a FreeBSD based LAMP (FAMP) stack package that installs all the 
necessary bits with one pkg install command.

In summary we should pair down base and use ports to our advantage. 
Unless the proposal is to add some feature written in rust that cannot 
live in ports or if the proposal is to rewrite FreeBSD into rust (which 
I vehemently disagree with), there is no reason to consider adding rust 
to base.


-- 
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX:  <cy at FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.