Rust was pretty much designed to solve problems for Firefox. It's IMO the best bet Mozilla has made these last few years and we're just starting to see them reaping the rewards.
I don't know how this relates to the creator of Rust or its actual origin story, but Mozilla has been trying to get many of the same results out of C++ for a long time. You can look at the evolution of smart pointers in the codebase, along with more formal ways of representing error return codes (borrowed from MS COM), and general good practices.
It seems at some point they became aware of how unsuited C++ is for parallel processing, and how important it would be for browsers in the future. Even compartmentalization or running tabs in their own process is a form of parallelization. This requires an efficient way of sharing memory and preventing race conditions and errant writes, as well as a way to protect these processes from cross-site scripting attacks, buffer over- and underruns, etc.
Computing hardware has also moved on from the CPU-centric world and the gains in battery life from dedicated GPU hardware being used even for rendering tasks, and now for font processing and other things were too good to pass up.
I'm a long time follower of Mozilla's development, and extremely excited about what's happening with Firefox.
(I'm also currently a Chrome user, leaving in large part due to profile corruption issues and inferior built-in development tools. I hope to be able to run Firefox and WebRender on both Ubuntu and Windows.)
Yes, though more to HRESULTS from the Windows API. This meant return values could indicate success or a specific error which could be determined with macros.
Rust actually has a similar mechanism in its standard lib, the Result enum whuch resembles Maybe from Haskell, but has either a returned value if successful (which can be the empty object ()) or an Error.
XPCOM was modeled on the Microsoft version using the same vtable tricks that it used to enable dynamic dispatch through interfaces.
It was denintely a long term play. The worry i had was what if they get 80% down that road and find out it would t work for some reason (say they wouldn't be able to get performance high enough)? They’d have lost a TON of time and resources.
How much Rust is actually in the new Firefox? I'm not seeing any based on a casual click-around in the repo, though I'll freely admit I haven't scanned the entire source tree.
Edit: if there is any, can someone give me a link to the part of the source tree that has it?
Do they also have any write-up on how did they find Rust during these changes? Was the back count lower than usual? Did the see an increase on productivity?
These components were built as part of the Servo project and then ported to Firefox, so you'd probably just want to ask the Servo team directly. You can find them on IRC, in the channel #servo on irc.mozilla.org.
There is https://blog.servo.org/, but it's mostly gradual updates on things, not a general overview.
- The mp4 metadata parser. This has been shipping for a while now, and was the first shipped Rust code.
- The URL parser (rust-url). This is not shipping, because it's incomplete and there are some mismatches to deal with. But it exists.
- Stylo: Servo's CSS engine in Firefox. By far the biggest one, this is shipping in beta and nightly, and should be there in the 57 release for everything but Android
- webrender: Servo's GPU-focused renderer. Not shipping, can be flipped on in nightly. Still has work to be done
- encoding-rs: All encoding operations go through this now. Shipping
- The U2F stuff: A lot of the U2F code is in Rust. Shipping in nightly though I think it's still off by default (but that will change soon?)
- You can find "c api" rust crates scattered throughout, like mp4parse_capi, rust-url-capi, encoding_glue . These depend on the actual crate (usually, a crate that's published to crates.io) but expose an API that C can call into
- Finally, any dependency from crates.io is vendored in https://hg.mozilla.org/mozilla-central/file/tip/third_party/... . Note that this includes build time dependencies (so you'll find crates that deal with CLI parsing and terminal color info that aren't actually used by firefox). Despite the folder being labeled "third_party", a lot of that code is maintained by us, but in separate repos and published to crates.io. In particular, large chunks of Servo are reusable published crates.
I don't know if there's any one location for all the Rust code; it may not make logical sense to put the MP4 parser written in Rust right next to the CSS engine, for example. I believe that https://github.com/mozilla/gecko-dev is a mirror of the repo in question, and so we can use Github's search function to find every file that it detects as being a Rust file: https://github.com/mozilla/gecko-dev/search?l=rust (which finds 3,274 Rust files, 6,701 C files, and 22,722 C++ files).
