The really awesome thing with rust is how easy it is to make library code which can be called from any language including C and C++ (in most situations) - just as easily as writing a library in C or C++. In some situations even easier than C++.

Thus I can easily see rust replacing C/C++ as the default language for writing 'high performance libraries' in, for use in Ruby/Python/etc. It's usually more similar to what higher level programmers are used to too. You get to use functional code for a start.

But also exactly as in Firefox - libraries / modules can be written in Rust, and then brought in to replace existing C++ code. And I'm sure the ergonomics of this process will improve too.

If a C++ project lead / manager can say, in all honesty: "The x component needs to be re-written for whatever reason - either major refactoring for a desired feature, or performance, or to split out to use in another product. We can either do it in C++, or Rust, and Rust will garentee no new segfaults, we can trivially parellelise a lot of it for improved performance, etc. etc. with no major disadvantages..." then Rust will inevitably grow.

There's another thing I've noticed with Rust. I get a lot of some code benefits that I've seen from functional languages(understanding inputs/outputs, preventing mutation) from Rust's ownership model.

If you want full function? Just don't pass/use anything that's mut.

Need to break that contract for performance? You still have single-ownership which gives you 90% of the above but with no performance penalty.

You still get logic errors/etc but it's a great no-compromise solution when you can afford the time to get your ownership right.

> If you want full function? Just don't pass/use anything that's mut.

Not quite. There are still mutable globals (they just have to have to have the appropriate "I'm MT-safe" marker traits); and there's nothing preventing any function from performing any I/O that it desires. Even better, once specialization lands, generic trait-functions will be able to behave differently when called on different types, even if the special behavior isn't valid given only the public type-signature's assumptions.

That may be true (I haven’t run the math) but it’s on a very critical path, which is equally important, if not more so, than size.

Heck, if it is that small, but has that big an impact, that’s saying something good too, isn’t it?

WebRender is replacing the most core part of the browser. They are replacing the hardest part, not the stright-line simple code. I suspect that in Firefox, like in many projects, the most modules are relatively peripheral but represent a majority of the LoC.