Date: Mon, 31 Dec 2018 17:36:39 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Warner Losh <imp@bsdimp.com>, Eric McCorkle <eric@metricspace.net> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: RE: Speculative: Rust for base system components Message-ID: <20190101013632.72B15196B@spqr.komquats.com>
next in thread | raw e-mail | index | archive | help
If it requires rust it s/b in ports anyway. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert <Cy.Schubert@cschubert.com> or <cy@freebsd.org> The need of the many outweighs the greed of the few. --- -----Original Message----- From: Warner Losh Sent: 31/12/2018 07:48 To: Eric McCorkle Cc: freebsd-hackers@freebsd.org Subject: Re: Speculative: Rust for base system components On Mon, Dec 31, 2018 at 8:02 AM Warner Losh <imp@bsdimp.com> wrote: > > > On Sun, Dec 30, 2018 at 10:41 PM Eric McCorkle <eric@metricspace.net> > wrote: > >> Before I begin, I want to be clear that everything here is in the realm >> of speculative, long-term discussion. My goal is to start a >> conversation, not to propose anything concrete right now. >> > > Today, this is a losing bid. The cost for rust is high (both in terms of > people and added compile time), it's not well supported on all our > architectures (and its robustness on the ones it does support has only be= en > tested in limited scenarios), and there's 0 software it enables from day > one. Plus, since it's a fast evolving language, we'll still need the port= s > to support those things that use it today since the likelihood of a versi= on > mismatch is high (and supporting 1 version would be a big stretch, multip= le > version is right out). So any sane cost / benefit analysis says: way more > cost than benefit, forget about it. We simply don't have the man-power to > maintain a high-cost, zero-benefit component in the tree. Lord knows we > have a lot of non-zero-cost-with-almost-zero-benefit things in the tree > today that we need to get rid of. > > In the future, when there are actual replacement things written, or there > are new features written, that will shift the cost / benefit equation. An= d > the circumstances about what makes up base will also have shifted, if we'= re > lucky, and we'll be able to have a conversation. We imported perl and tcl > on the speculative notion that people would build great things. That neve= r > really panned out, and they became a high-cost burden to keep modern for > only minor benefit. And version skew in Perl was terrible by the end. For= th > and Lua live in the tree because they have benefit (though Forth will be > departing, most likely by 13, and definitely by 14). They are also small > and easy to update to new versions. > > And we can't say, with certainty, that if a bunch of rust things show up > we'll use them in base. We'll have to see what they provide to benefit th= e > system. > > TBH, there's a stronger case for python than rust: there's actual python > scripts in the tree today that we have to install a port to use. And ther= e > the benefit, while not zero, is small and the effort is large compared to > just dragging it in as a port, so it hasn't been done. It's another fast > evolving language that requires multiple versions as well... > > So write something that everybody wants, that must be in base, and that > requires rust, and then we can have the conversation... > Just re-read this. It sounds a little more negative than I wanted to come off. I'd only wanted to say today the needle is on 'nope' and I hope people write enough cool stuff to justify moving the needle off 'nope' :) The last part of that message seems more muted than I wanted. Warner _______________________________________________ freebsd-hackers@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190101013632.72B15196B>