From MozillaWiki

Oxidation is a project to integrate Rust code in and around Firefox.

Rust support has been required on all platforms since Firefox 54, and the first major Rust components were shipped in Firefox 56 (encoding_rs) and 57 (Stylo). Moving forward, the goal of Oxidation is to make it easier and more productive to use Rust in Firefox, and correspondingly to increase the amount of Rust code in Firefox.

This page is intended to serve as the starting point for all matters relating to Rust code in Firefox: the what, the why, and the how.

Guidelines

The goal of this section is to provide some high-level guidelines about when Rust should be used.

In summary, Rust should be used in the following situations.

For new components and completely rewritten components there should be a strong bias towards using Rust, especially for code around Firefox but not within Firefox.

For existing components it's more complicated!

The following sections have more detail. Ultimately, choice of language for a code component is an engineering decision, with corresponding trade-offs, and is best decided by individual teams.

Rust Strengths

Rust has the following strengths.

Memory-safety and thread-safety. Crashes and security vulnerabilities are much less likely. (Roughly 70% of critical security vulnerabilities are due to memory safety bugs.)

High performance. In particular, the safety enables code that is designed more actively for performance, especially parallel performance.

Nimbleness. The safety enables significant changes to existing code to be made quickly and with confidence.

Expressiveness. It is powerful and pleasant to use, particularly once a moderate level of experience has been reached.

Excellent package management and an extensive ecosystem.

Excellent compiler error messages.

Excellent documentation.

A friendly and helpful community.

Rust Weaknesses

One major issue with Rust relates to personnel.

There is a wide variety of experience levels within Mozilla, for both coding and reviewing.

Rust's learning curve is steep at the start, which can be intimidating. (The new borrow checker released in Rust 1.31 helped greatly with this.)

There are also technical challenges.

Compilation is slow.

Crossing the C++/Rust boundary can be difficult.

See "Blockers and obstacles" below for more details about work being done to remedy these weaknesses.

Recommendations

Therefore, Rust is most suitable in the following situations.

For components that are relatively standalone, with small and simple APIs. This minimizes the C++/Rust boundary layer issues. Infrastructure tools that are standalone programs are ideal. Note that it's good software engineering practice to write loosely-coupled components anyway.

For components that process untrusted input, e.g. parsers. Rust's memory safety is a big help here. See the "Writing parsers like it is 2017" paper for lots of good details.

For components where parallelism can provide big performance wins.

For components where Servo has demonstrated success.

In terms of where to keep Rust crates, there are three options.

Put the crate in mozilla-central or in Servo's repository. For binding code, the decision to put it into Gecko or Servo can be difficult. The best choice depends on the details of the binding code in question.

Put the crate on crates.io and use Cargo to access it at build-time. This is only suitable for highly general-purpose crates, such as smallvec .

Put the crate somewhere else (e.g. a separate GitHub repository), and regularly vendor it into mozilla-central. This makes sense for pre-existing third-party crates that we choose to import. Otherwise, this option is not recommended, because vendoring is something of a hassle.



In general, erring on the side of tighter coupling is advisable. For example, the heapsize crate used in memory reporting was moved to crates.io, and then other crates came to depend on it. Later on it needed major API changes, and we ended up replacing it with a new crate called malloc_size_of (stored in Servo's repository) because that was easier than modifying heapsize .

Documentation and assistance

Rust in general

Rust in Firefox

Policy

Rust in Firefox docs

Getting extra help

The Rust channel on Mozilla's Matrix network contains lots of people who know about both Rust and Gecko.

Are you new to Rust and not sure if your Rust code could be improved? The following people can review Rust patches for Firefox from an "is this good Rust code?" point of view. Alexis Beingessner (:Gankra) Josh Bowman-Matthews (:jdm) Emilio Cobos Alvarez (:emilio) Manish Goregaokar (:manishearth) Nika Layzell (:nika) Cameron McCormack (:heycam)



Rust Components

Within Firefox

Statistics

Shipped

In progress

Proposed

WebMIDI: bug 1201593, bug 1201596, bug 1201598

Gamepad code: bug 1286699

Replace the telemetry module(?) Why Rust? The existing C++ code has a history of threading problems.

Replace DOM serializers (XML, HTML for Save As.., plain text) Why Rust? Need a rewrite anyway. Minor history of security vulnerabilities.

Expose Rust API to JS Debugger: bug 1263317

Generate Rust bindings for IPDL actors (bug 1379739)

WebM demuxer: bug 1267492

Parallel JS parsing: fast preparse to find function boundaries, parse non-overlapping functions in parallel with a unification step to handle free names and such (no bug on file yet) Why Rust? Parses untrusted input. Requires safe threading. And generally, Rust is a better language than C++ for parsers, due to strong typing, algebraic data types, and pattern matching.

Crash reporter Why Rust? Code needs rewriting, useful Rust crates exist that could be used.

Sync/FxA components Why Rust? Single safe and performant implementation which is shared across all our products.

libcubeb Audio backend for Windows (WASAPI)

Replace the XML parser, possibly via c2rust: bug 1611289 Why Rust? Parses untrusted input, replaces expat, a 3rd-party library with a history of frequent security vulnerabilities.

Rewrite the ICE stack used by WebRTC; bug 1616966 Why Rust? Works with network data.



Outside Firefox

Completed

Testing GeckoDriver, a WebDriver implementation for Firefox integrated via marionette protocol: bug 1340637 (standalone releases) grcov, a tool to collect and aggregate code coverage data for multiple source files, used in Firefox CI.

Build system, etc. sccache, compiler cache with s3 storage. Caching C++ and Rust compilation, used in Firefox CI. Parts of mozsearch, the backend for the Searchfox code indexing tool. makecab, a reimplementation of Microsoft's makecab tool. Used to compress PDB files before uploading to symbol server in Firefox CI. dump_syms, a reimplementation of Google Breakpad's dump_syms tool for Windows. Used to parse PDB files and print out Breakpad-compatible symbol files. Why Rust? Doesn't rely on Microsoft closed-source libraries anymore, can be cross-compiled and run on a non-Windows host, is an order of magnitude faster, takes less than a third of the memory, produces better symbols and relies on an active and friendly upstream symbolic

Application Services, server-side autopush-rs Rust async based websocket server that implements Mozilla's push/webpush/broadcast protocols. Why Rust? Concise code with the memory efficiency of C. Megaphone, a real-time update broadcast server for Firefox. fxa_email_service, a service for sending email to Firefox Accounts. pairsona, a tool to associate instances of firefox.

Application Services, client-side various sync-related components used on iOS and Fenix, includes a cross-compiled FxA Rust client, and storage/syncing of bookmarks, history, logins, tabs and webextensions data.

fix-stacks, a stack frame symbolizer: bug 1596292 Why Rust? High performance needed, a single implementation can replace multiple platform-specific scripts, and we can use the symbolic crate to do all the hard parts.



In Progress

IPDL Parser: bug 1316754 Why Rust? Rust is a much better language than Python for writing compilers, due to strong typing, algebraic data types, and pattern matching.



Blockers and obstacles

This section lists areas where Rust integration could be improved.