Hacker News Reader

Comment by smegel | Hacker News Reader

Are there any blogs about how Rust is integrated into Firefox (a mostly C++ program) - i.e. how the Rust runtime is invoked, garbage collection etc?

View on HN

Hi, I'm a Servo developer who worked on some of the Rust code that's in Firefox. Calls between C++ and Rust code in Firefox all go through "extern C" functions. Some of the code involves reference-counted smart pointers. We use RAII wrapper types in both Rust and C++ to ensure that refcounts are incremented and decremented correctly on either side of the FFI boundary.

P.S. This old blog post is not about Rust-in-Firefox, but it does cover a related topic: How the Servo browser engine (written in Rust) interacts with the Spidermonkey JavaScript engine (written in C++ and embedded in both Gecko and Servo), including garbage-collected JavaScript objects:

https://research.mozilla.org/2014/08/26/javascript-servos-on...

Cool thanks.

Are there any engineering openings at Mozilla?

You can check out this page: https://careers.mozilla.org/

Rust doesn't have any more runtime than C, and also doesn't have a GC. Servo has bindings into SpiderMonkey's GC so that the JavaScript stuff works properly, but that's only that part.

That said, I don't think there are any direct blog posts about it; Firefox's other code just sees Rust as C code, as far as I know. (I don't work on Firefox though so I could be wrong about some details.)

I swear I had read Rust had optional GC at one point. And similarly Rust wanting to own main(). Maybe not then.

I don't know the precise history, but at one point, it did have a "gc" type, which I believe was demarcated by the `@` sigil. So, for example, `@T` was a garbage collected pointer to `T`. IIRC, the actual garbage collector was simplistic, and was mostly just reference counting under the hood. At some point (in 2014, I think), the GC type went away. Since then, there has never been any serious talk of adding an optional GC to Rust proper, although many folks have worked/written about writing their own.

This is pretty accurate; however, a very long time ago there was a tracing GC!

Are you sure? I thought @ was reference counted in 0.6 and then removed after. Was it before that?

I don't have any citation beyond "Graydon told me one time". It was like, very very long ago, possibly before @T even existed.

IIRC it was a mark and sweep GC in the OCaml implementation.

That sounds about right.

Wow, I can't believe I have been reading up lately on official Rust documentation and still I was under the impression that Rust had optional GC. Thanks for sorting me out...

Well, I think is sort of does when you use the Rc types, right? It's just much more explicit than a type modifier, it's a type wrapper that requires requires some level of additional code ornamentation in some instances when using later as well. It's just not really any different than using a library in C++ that offers the same, except that in Rust's case the library is part of the stdlib.

Rust had almost everything at some point :)

Rust binaries do define a "main", and setting that up is the runtime's job, like C. But you can also make a library that needs no main at all.

> That said, I don't think there are any direct blog posts about it; Firefox's other code just sees Rust as C code, as far as I know.

So it means the compiled binary ends up in a simple compatible C ABI? thats pretty nice, if thats the case.

But giving the project is using LLVM, even C++ ABI would be achievable without too much effort (i guess).

To clarify, Rust has its own ABI, just like C++ has its own ABI. And just like C++, you can expose a C ABI if you want by defining special functions. In C++, it's an `extern "C" { ... }` block, and in Rust, it's a `extern "C" fn foo() ...` function declaration. You can see an example here: https://github.com/rust-lang/regex/tree/master/regex-capi

Adding C++ ABI support is a significant effort.

> To clarify, Rust has its own ABI, just like C++ has its own ABI. And just like C++, you can expose a C ABI if you want by defining special functions. In C++, it's an `extern "C" { ... }` block, and in Rust, it's a `extern "C" fn foo() ...` function declaration.

Ohh, Now i got it. But its pretty good thing to have anyway. C ABI is the lingua franca anyway to communicate to any language, even C++.

> Adding C++ ABI support is a significant effort.

Ok. So if has its own ABI, im sure it would be a pretty hard undertaking to be compatible with C++.

I was guessing if maybe Rust had managed to squeeze and reuse the C++ ABI.. but sure, giving Rust is not that much alike C++ this would probably be a bad decision for small gains.

Thanks for clarifying.

bindgen actually has the option to generate wrappers for C++ methods and other stuff for Rust to call. We don't use this, but we do use its ability to generate templates and stuff.

The other way around -- getting Rust to use the C++ abi -- needs compiler changes and also has questionable benefits.

> getting Rust to use the C++ abi -- needs compiler changes and also has questionable benefits.

Yes.. Im sure is not worthy it overall.

Yup, with bindgen and rusty-cheddar you can build interfaces both ways that just talk over a C ABI. It's really, really nice.

In fact Rust in general is awesome for going to a wide range of platforms. I've got a project right now that runs on MSVC-x64/x86, Linux-x64, OSX-x64, Android-armv7, Android-x86, Linux-armv7 and Emscripten. Single codebase and interacting with various languages(C#, C++, Java) via the C ABI. Rust even cross-compiles my C source via GCC crate so I can use C libraries and build for any of those targets from my host(win32) machine.

Also, having just spent a few hours fucking around with linker flags in Qt I can't stress enough how awesome Cargo, Crates.io, Rustup and the sane defaults Rust has. It really is an incredible ecosystem.

It's not a blog, but Rust Belt Rust 2017 [1] (a conference I help organize) will have a talk "The Story of Stylo: Replacing Firefox's CSS engine with Rust" [2]. The conference is in Columbus, Ohio, and is reasonably priced.

[1]: http://rust-belt-rust.com/ [2]: http://rust-belt-rust.com/sessions.html

Are there any stats yet on improvements in memory safety within Firefox attributable to Rust. In theory, it could be as much as 50% fewer based on the original premise of Rust removing whole classes of programmer errors, but are there stats from Rust being in the wild? The CSS replacement reminded me that there should be something to compare.

> are there stats from Rust being in the wild?

I don't know, but if I recall correctly, nobody has ever reported a memory safety bug to ripgrep, or even the underlying regex engine. I don't really know how many people use ripgrep, but it's not zero.

I can assure the lower bound is at least one. Thanks for boosting my productivity!

I use it everyday, several times per day. Thank you for you such a useful utility.

Well, everyone who's using VS Code is using ripgrep, and a year ago Microsoft said it had half a million active users, and the number has presumably grown since then.

Doesn't ANY rewrite (regardless of whether there is a change in language) reduce bug-count, simply because all the requirements are more clear in advance and the engineers have had more time to think about a suitable architecture?

Nope. Churn (= number of lines changed) is actually pretty well correlated with bug count.

I don't have a precise reference off-hand, but I believe I read it in "Making Software: What Really Works, and Why We Believe It".

Obviously you'll probably get closer to what the software is intended to do, but it probably won't reduce bug count in the short term. In the long term, you might end up with fewer lines of code overall (which is also correlated with overall bug count).

> Churn (= number of lines changed) is actually pretty well correlated with bug count.

Is a rewrite considered as bunch of line changes or not? I would say not.

Also, can I assume that by "correlated with" you mean "positively correlated with"?

If so, isn't a rewrite reducing bug count because you'll end up with far fewer "changed" lines?

I would assume a rewrite counts as a bunch of line changes -- absent evidence to the contrary. Obviously, if you're changing the language that changes the equation, some bugs which can happen in C++ simply cannot happen in Rust, for example.

(And yes, I meant "positively correlated with".)

Reply on news.ycombinator.com