[pkasting]

Our team is staffed by engineers. We respond well to discussions of tradeoffs. If you'd like to present a proposal for writing parts of Chromium in Rust and speak in depth to the exact costs and benefits, we'd absolutely consider it. I know this because we _have_ been doing some of this consideration; a number of people on the team have floated the idea of using Rust for some parts of Chromium.

But a real plan to do this requires a great deal of thought and serious consideration about how you get from here to there, whether there are long-term engineering velocity costs, etc. You don't just say "Rust is more memory-safe" and let that phrase alone mean "so obviously you're a dinosaur if you don't switch to it".

Even Mozilla is taking a lot of time and effort to introduce Rust-based components to Firefox. Making big changes to enormous projects used by huge numbers of people is not something you do lightly.

Still, though, we'd happily consider it.

[pcwalton]

In late 2018, using Rust is a lot more serious of a proposal. But, in practice, I don't think the case for Rust in the browser would be nearly as compelling if we hadn't shown that it can be done. That's one strong reason for browser engine diversity: different engines can try different things.

I think it's fair to say that a Rust proposal would have been dead-on-arrival a couple of years ago. It'd be seen as far too risky. It would have remained so in a world where Blink was the only browser engine.

It's a classic innovator's dilemma: with fewer browser engines, the fewer risks the industry will take. More browser engines allow more seemingly-risky innovations (such as parallel styling/layout, or Rust) to break through.

[danmaz74]

A very nice property of open source software is that you can fork it, "show that it can be done" without having to start from scratch, and if the results are provably better, get your approach adopted.

The trickiest part is the proving that the different approach technology is enough better to warrant a switch. Very often, new approaches don't live up to expectations (not saying this is the case for the tech you're talking about).

[pcwalton]

1. This is actually discouraged for many projects (e.g. LLVM), because of the possibility that someone does a lot of work and then their results are not accepted.

2. The issues here don't have to do with whether the technology "works" (it does), but rather "developer velocity" and other more social/political concerns.

[danmaz74]

I understand your points, but I would suggest to consider a different point of view:

1. When you're experimenting with a seriously new technology or approach, the most likely outcome is that you'll fail, especially at the market adoption level. Being able to conduct your experiment at a lower cost is still a net positive, except for one point: having invested less, you are more likely to abandon the experiment early, because of the sunken costs fallacy. That doesn't necessarily need to be the case.

2. Developer velocity/productivity is something that you can demonstrate - as long as the difference is consistent, like, not 10% faster, but 80% faster. Other social/political concerns are a different thing, but really, gaining market adoption based only on those is VERY difficult - if that wasn't the case, I don't think we would be having this discussion at all, because Firefox would have a much higher penetration.

So, the point is, how is having a completely separate codebase going to help with having success? It could attract a higher number of idealistic developers, but the additional work required is very likely to negate that advantage.

[pkasting]

Rust as a language was significantly less mature a few years ago; I think that's the bigger factor here.

It certainly doesn't hurt to do compelling things in Rust in a browser engine, but doing compelling things in Rust in some other project entirely would also be motivating.

To look at it from another angle, Mozilla itself had a reason to try to tackle some problems with Rust. It didn't need a competing browser engine using Rust in order to move forward with that plan. And the plan wasn't "well, we'll try this because we can somehow fall back on a competing engine if this doesn't work". So if your argument were true, I don't see how Mozilla could have moved on this either.

In the end people do things because the potential benefit justifies the costs and risks, and having a competitor do something is not the only way of determining potential benefit.

[vitorgrs]

Would Google consider using Play Ready on Windows instead of Widevine? Widevine perf is worse on WIndows, because it's all software frame decoding, and because of that, doesn't support 1080p or 4k Netflix videos on Windows.

Edge does. I'm curious to see how this will work.