Speculative: Rust for base system components

Enji Cooper yaneurabeya at gmail.com
Thu Jan 3 16:22:36 UTC 2019


> On Jan 3, 2019, at 04:46, Eric McCorkle <eric at metricspace.net> wrote:
> 
> On 1/2/19 1:29 PM, Cy Schubert wrote:
> 
>>> 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.
> 
> That doesn't represent what I wrote at all, and is bordering on a
> strawman argument.  Nobody to my knowledge is suggesting rewriting
> everything, nor would that be possible.
> 
>> 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.
> 
> And that seems to be the point of convergence in all this, which is fine
> by me.  I was looking to discuss the options and figure out the best way
> forward.

Going back to my previous statement, I think writing a service monitor (to work alongside init and rc) in modern C++/rust would be a good item to undertake.

I’d be willing to do this with someone else, as a research project/to demo how rust could be used.

Given prior comments about rust binary sizes and the fact that the default linking option is mostly static, a “mission critical binary” like this (or rescue?) would be a good candidate for rust.

Cheers,
-Enji

PS let’s call the discussion mostly closed and start working on prototypes instead of beating a dead horse further.


More information about the freebsd-hackers mailing list