There are obvious benefits to writing new things in Rust. In general, the main barrier to doing so is the extent to which they may interact with existing C++ code, and the adequacy of our tooling for managing that interaction.
In London last year, we had a meeting to discuss how we wanted to use Rust for DOM code. The consensus of that meeting was that Rust code could be useful as a backend for DOM functionality, but that it still needed to be wrapped inside a C++ shell to handle reflection, cycle collection, and interaction with the rest of the (C++-based) DOM. Our tooling (specifically around bindgen) has matured significantly since then, largely to support stylo. But there are still a lot of unsolved use cases, and some of them (like inlining) are pretty hard to solve. The costs of haphazard integration can be high, specifically to performance, safety, and complexity/maintainability. So I think we want to tread carefully here. 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. 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. Ehsan, as module owner, wdyt? bholley [1] https://wiki.mozilla.org/Modules/All#C.2B.2B.2FRust_usage.2C_tools.2C_and_style On Mon, Jul 10, 2017 at 3:29 AM, Nicholas Nethercote <n.netherc...@gmail.com > wrote: > Hi, > > Firefox now has multiple Rust components, and it's on track to get a bunch > more. See https://wiki.mozilla.org/Oxidation for details. > > I think this is an excellent trend, and I've been thinking about how to > accelerate it. Here's a provocative goal worth considering: "when writing a > new compiled-code component, or majorly rewriting an existing one, Rust > should be considered / preferred / mandated." > > What are the obstacles? Here are some that I've heard. > > - Lack of Rust expertise for both writing and reviewing code. We have some > pockets of expertise, but these need to be expanded greatly. I've heard > that there has been some Rust training in the Paris and Toronto offices. > Would training in other offices (esp. MV and SF, given their size) be a > good idea? What about remoties? > > - ARM/Android is not yet a Tier-1 platform for Rust. See > https://forge.rust-lang.org/platform-support.html and > https://internals.rust-lang.org/t/arm-android-to-tier-1/5227 for some > details. > > - Interop with existing components can be difficult. IPDL codegen rust > bindings could be a big help. > > - Compile times are high, especially for optimized builds. > > Anything else? > > Nick > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
