On Mon, Jul 10, 2017 at 5:39 PM, Nicholas Nethercote <n.netherc...@gmail.com > wrote:
> On Tue, Jul 11, 2017 at 2:33 AM, Bobby Holley <bobbyhol...@gmail.com> > wrote: > >> >> In other words, I think we should encourage people to consider Rust for >> new code, but also make sure that we have a thoughtful and informed >> discussion about whether a use-case makes sense and how best to support it. >> > > Definitely! I deliberately described my "Rust should be considered / > preferred / mandated" goal as "provocative" :) We should think big, and > then put engineering effort in where it makes sense and will have strong > benefits. > > >> Right now we have a module that's intended to govern decisions on these >> issues [1]. However, the peer list for that module seems oriented around >> C++ and build system expertise, and is sparse on people who have been >> deeply involved in the Rust integration efforts over the past year. >> >> So we could expand that group with expertise to tackle Rust integration >> issues. Or it could charter a committee of such experts to do so. Or some >> combination. Either way, I think we want some amount of steering here, and >> I can think of a handful of names whose input is likely required to get it >> right. >> > > That module's name is "C++/Rust usage, tools, and style", and its > description is "Aspects of C++ use such as language feature usage, standard > library versions/usage, compiler/toolchain versions, formatting and naming > style, and aspects of Rust use as needs arise" > > To me that feels orthogonal to the notion of encouraging the adoption of > more Rust components in Firefox. That kind of encouragement feels more > project-wide, and so IMO would fall under the "mozilla-toplevel" component. > IIRC Brendan resigned ownership of that module a while back but he's still > listed as the owner at https://wiki.mozilla.org/Modul > es/All#mozilla-toplevel. So that leaves things in an uncertain state. > > If I were the owner of that module I would consider implementing a policy > something like the following: > > "When a person writes a new compiled-code component, or majorly rewrites > an existing one, they should strongly consider writing it in Rust instead > of C or C++. Such a decision will depend on the nature of the component. > Components that are relatively standalone and have simple interfaces to > other components are good candidates to be written in Rust, as are > components such as parsers that process untrusted input." > I think this is pretty uncontroversial. The high-level strategic decision to bet on Rust has already been made, and the cost of depending on the language is already sunk. Now that we're past that point, I haven't heard anyone arguing why we shouldn't opt for memory safety when writing new standalone code. If there are people out there who disagree and think they have the arguments/clout/allies to make the case, please speak up. The tradeoffs come when the code is less standalone, and we need to weigh the integration costs. This gets into questions like whether/how Rust code should integrate into the cycle collector or into JS object reflection, which is very much a technical decision that should be made by experts. I have a decent sense of who some of those experts might be, and would like to find the most lightweight mechanism for them to steer this ship. > > It could do with some tweaking and feedback, but in principle I don't see > why such a policy couldn't be implemented right now. I don't know where > this policy would be written down, though! > > Nick > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
