WebRender has come out of Mozilla's Servo browser engine project, which has had influence on the development of Rust itself. The language and the browser engine have been developed together, so this and other parts of the Quantum project [1] (mostly bringing parts of Servo into Firefox) are like the culmination of all this work, and a validation of the language.

[1] https://wiki.mozilla.org/Quantum

Because development of this particular project has been a large driving force of Mozilla's interaction with Rust.

    <rust-evangelism-strike-force>
        FEARLESS CONCURRENCY
    </rust-evangelism-strike-force>

Rust makes it easier to write bug-free concurrent code. Webrender relies on this and I'm not sure Mozilla could have pulled it out in C++ in the same time frame, if at all.

I think that's pretty presumptuous. My experience is that rust's checking is great, but much easier and safer concurrency can still be enabled by some work with data structures and program architecture.

IMozilla engineers have specifically said Stylo (Quantum Style whatever) would be impossible in C++, because they actually tried it in C++. Presumably it'd be the same with WebRender.

Impossible is a strong word. Architecture makes a very big difference. They can claim it is impossible, but it really doesn't make sense. I'm surprised anyone would just take their word for it.

Trying to use raw threads and ad-hoc futures is going to be difficult, but fundamentally concurrency is about separating data by dependencies.

Dependency graphs that pass data around combined with lock free data structures can be used to isolate parts of the program so that dealing with concurrency is one generic part of the program.

Since Rust is a memory safe language with nearly the same performance as C

EDIT: Parent commenter edited the comment to append "with the same performance as C", so you can ignore my reply.

So is Python, JavaScript, Java, OCaml, Haskell...

A more distinguishing feature of Rust is not only that it is memory safe but also that it doesn’t have a GC.

In any case the presence of a single unsafe block can make the program no longer memory safe. Of course, if used appropriately, it vastly reduces the audit surface compared to something like C++.

None of those have nearly the same performance as C.

GP edited the comment, so now my reply looks silly.

OCaml can have nearly the same performance as C.

Is GC a negative? I’ve yet to see anyone go “well I would’ve written this in Golang but it’s got GC”. Even that new Windows driver style, where it’s split in two, can have half of it being GC’d, right? Looking at https://en.wikipedia.org/wiki/Windows_Driver_Frameworks at least.

> I’ve yet to see anyone go “well I would’ve written this in Golang but it’s got GC”.

This is a dealbreaker in a lot of contexts where garbage collection pauses would be unacceptable.

Yes, GC is a negative. There is a huge literature in measures to mitigate its negatives. These always involve trading off one against another, and libraries are frequently incompatible with any particular mix of them.

A GC is literally the only reason I haven't tried go.