Good to see some internal motivation from Mozilla's side for a bridge between rust and c++. This will be needed to drive major adaptation of rust.
Transitioning Firefox's rendering engine from Gecko to Servo
161–170 of 219 posts
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#162Earlier quoted context omitted.
Rust should be just as fast as C++ and C. Benchmarks are hard of course because optimizations and such. But if Rust is significantly slower, than it is a bug.
I think you may have misunderstood my comment, as I did not mean to disparage Rust's speed nor imply it was slower than C/C++. Rust, at best, can match C/C++. But Rust cannot be faster than C/C++; therefore, by function of simply being rewritten in rust (and not because it was rewritten ), that does not, in and of itself, make the resulting executables faster.
Rust _can_ be faster than C or C++. The possibility is different than always, though.
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#163By the time they will finally make the switch, Firefox' market share will probably have plunged to a very low single digit percentage.
Actually, it's already there. Has been since last year.
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#164Earlier quoted context omitted.
There's no plan to write a new JS engine at Mozilla, FWIW.
And they shouldn't...let's move forward... to WASM (Web Assembly)! Which, also posted on front page of HN recently, a user's medium blog on compiling Rust to WASM. https://medium.com/@chicoxyzzy/compiling-rust-to-webassembly...
Except, like, JS isn't going to die any time soon, and realistically, implementing a new JS or WASM VM isn't actually that interesting to do: the big risk in a JITing VM that Rust cannot save you from is behaviour of your JITed code, which makes memory safety far harder to enforce.
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#165Earlier quoted context omitted.
Rust should be just as fast as C++ and C. Benchmarks are hard of course because optimizations and such. But if Rust is significantly slower, than it is a bug.
I think you may have misunderstood my comment, as I did not mean to disparage Rust's speed nor imply it was slower than C/C++. Rust, at best, can match C/C++. But Rust cannot be faster than C/C++; therefore, by function of simply being rewritten in rust (and not because it was rewritten ), that does not, in and of itself, make the resulting executables faster.
There is no proof that any existing C/C++ implementation can produce code that is globally optimal. I wouldn't say that it is impossible for Rust to beat C/C++...there is plenty of room for improvement in compiler optimization engines.
I would even say that the room for improvement is potentially greater for rust than it is for C/C++, due to the type system. It hasn't been taken advantage of much yet, but MIR is one of the first steps to do so. It's an intermediate stage representation, like llvm's IR, but with all type resolution intact. There are plenty of known and even formally proven code optimizations that can only be used if certain guarantees are proven (such as the guarantees made by a strong type system).
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#166Earlier quoted context omitted.
I think calling Servo "experimental" is still somewhat confusing as it stands today. I think the initiatives to implement engine in Rust is no longer an experiment. The language has gained some serious production attractions in the last year or so as Rust reached 1.0. While Rust isn't as "popular" as Go, Rust community is strong. I think however it is better off to interpret that Mozilla is getting more serious on re…
While writing a browser in Rust might not be, per-se, particularly experimental anymore, nobody has written a browser engine from scratch since KHTML in 1998, and with the growth in complexity of the web since then it's unclear whether one can write a new browser engine from scratch without spending years reverse-engineering the competition—we've come a long way in the past decade in better defining many historically…
> it's unclear whether one can write a new browser engine from scratch without spending years reverse-engineering the competition
That's to Mozilla's advantage, given that no company in the world has more historical experience reverse-engineering browsers. :P
> how does that interact with things like the Grid Module?
Servo devs have definitely identified places in the HTML spec which, entirely by accident, require serial behavior. Having a pervasively-parallel browser will hopefully go a long way towards preventing such accidents in the future.
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#167I've seen this before: >> At some point in mid-2017, all new CSS will be built with Quantum plane parts, not Gecko. Going forward, it will be much easier and more enjoyable to implement new CSS properties. Which makes it easier for folks in the open source community to contribute. If you're not careful this can drag on for years with half the stuff done one way and half the new way - especially once you reach the poi…
A good way to force this along is to have a champion for the work, and an automated burndown metric that random devs can watch and influence. Mozilla is pretty good at the latter, cf. https://arewefastyet.com
Seems like Safari is doing better than everything else if I'm reading the charts right.
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#168Earlier quoted context omitted.
Not if in the process they'll make all the existing add-ons incompatible and therefore lose all their remaining market share.
I disagree. If they are able to deliver a browser that's much faster and consumes less battery, I believe that would be enough to make a lot of users change their browser. Maybe I'm wrong and I'm not a good example, but I the only add-ons that I have installed that I really care about is 1password (which is easy to live without, as I can use the stand-alone application) and HTTPS everywhere (which just means that I h…
AFAIK, about 40% of Firefox users don't have any add-ons.
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#169Earlier quoted context omitted.
And they shouldn't...let's move forward... to WASM (Web Assembly)! Which, also posted on front page of HN recently, a user's medium blog on compiling Rust to WASM. https://medium.com/@chicoxyzzy/compiling-rust-to-webassembly...
Except, like, JS isn't going to die any time soon, and realistically, implementing a new JS or WASM VM isn't actually that interesting to do: the big risk in a JITing VM that Rust cannot save you from is behaviour of your JITed code, which makes memory safety far harder to enforce.
Right, JS isn't going anywhere. But once WASM is able to run everywhere, anybody attempting to make high performance web apps would ideally want to write it in WASM. A lot of what JS does on the web is plenty fast and won't really benefit much from JS being multi-threaded/faster.
Sites using JS to run simple scripts or to fire api calls/etc. will continue to use JS, no reason to use WASM.
Also, I believe WASM is truly compiled code and not JIT ran? I may be wrong...but pretty sure that was the whole point of creating it. Native app performance in the browser... that will take a big bite out of the app stores that take a good cut of revenue and control what can and can not be in the store.
And sure, WASM can also have memory safety problems, especially with C/C++ being the primary languages to target WASM from. But that's also where Rust would shine, making it much more safe when compiled to WASM.
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#170Call caniuse, flexbugs, quirksmode, stackoverflow and it's companion codepen on the deck, there will be some action! creating a renderer in 90% of the work, the other 90% is documenting its bugs and quirks.
Correct. That's why it's such a massive task.
Servo is pretty decent at supporting a lot of web standards now. Unfortunately, the real web is made of quirks and implementation targeting workarounds.
I think the biggest lesson from Servo is that entry barrier to the web market is already much higher than we would like it to be.
Having a great new web engine supporting 100% of web standards does not get you even close to being ready to serve the web.
And the willingness of web developer community to take the "one browser only feature" bait is a major part of the problem.