5 ms·

How do I convince Chromium to adopt parallel engine components written in Rust, in this world? They won't do it, because the entire team at Google is staffed b

How do I convince Chromium to adopt parallel engine components written in Rust, in this world? They won't do it, because the entire team at Google is staffed by C++ folks. How is that a better outcome?

sureaboutthis 8y ago
The same way you would convince any other browser vendor to do the same thing. Good luck with that. But let's not forget that Firefox, Opera, et al, are not going away and no one is forcing you to use Chrome or chromium and there probably won't be any real downside either.
- holtalanm 8y ago
  Well, Opera uses Blink, and apparently according to some folks in this thread that is equivalent to using 'big bad Chrome'
pkasting 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
        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.
- vitorgrs 8y ago
  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.
holtalanm 8y ago
As a web developer, why would I even care about that? I care more about whether it adheres to web standards; or in the absence of a standard, whether it is in-line with other leading browsers. If all of our leading browsers use the same engine, the answer to that is one and the same. I mean, I get the point you're trying to make, but the argument doesn't really fit with what I'm saying. As far as I'm concerned go ahead and rewrite Blink in Rust or Go or Common Lisp. As long as it is the main engine, or adheres to the web standards, it really makes no difference to me.

sureaboutthis 8y ago

The same way you would convince any other browser vendor to do the same thing. Good luck with that. But let's not forget that Firefox, Opera, et al, are not going away and no one is forcing you to use Chrome or chromium and there probably won't be any real downside either.

holtalanm 8y ago
Well, Opera uses Blink, and apparently according to some folks in this thread that is equivalent to using 'big bad Chrome'

pkasting 8y ago

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 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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.
vitorgrs 8y ago
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.

holtalanm 8y ago

As a web developer, why would I even care about that? I care more about whether it adheres to web standards; or in the absence of a standard, whether it is in-line with other leading browsers. If all of our leading browsers use the same engine, the answer to that is one and the same. I mean, I get the point you're trying to make, but the argument doesn't really fit with what I'm saying. As far as I'm concerned go ahead and rewrite Blink in Rust or Go or Common Lisp. As long as it is the main engine, or adheres to the web standards, it really makes no difference to me.