> Damn, we don't know could the browser engine written in Rust work or not, despite the fact writing a browser engine was the goal of Rust from the day one.
We kind of do at this point. It renders reasonably well, faster on some workloads than existing browsers. The majority of work still to do involves chasing down rendering bugs, and building a shell around it. That's a lot of work, but it's the sort of work that isn't breaking new ground like the work with integrating JS and the DOM and a GC into Rust, it's regular boring work. (There's some exciting things going on - see WebRender - but they're mostly theoretically optional and the browser would work perfectly fine and performant if it had much of the same infrastructure as it has today.)
> By the way, network card driver can be written in LuaJIT (and perform well) too[1]. Shall we do it?
Lua's already used for some embedded development. Using LuaJIT as a network driver in some cases seems reasonable to me - especially if you were running it as a userspace process under a microkernel.
Kind of, indeed. Last time I've seen comparison of html5ever with plain C HTML parser, we suddenly realized it is painfully slow, 'uses the proof-of-concept DOM' and whatnot[1]. So we don't know. We've yet to see anything written in Rust used in production environment, just anything.
> Using LuaJIT as a network driver in some cases seems reasonable to me
Why don't we see LuaJIT zealots in every thread on every board in every discussion of something written in C or C++, I wonder?
> we suddenly realized it is painfully slow, 'uses the proof-of-concept DOM' and whatnot
Err, no, you've misread that. html5ever serializes into an arbitrary datastructure, provided by the program using html5ever. It also ships with its own datastructure to serialize into for testing purposes (the "proof-of-concept DOM"), which Servo does not use. It's therefore not a benchmark of html5ever as used in Servo.
More reasonable would be benchmarking Firefox's HTML parsing as it stands in Firefox against Servo's HTML parsing, from text to a fully built up DOM as usable by the rest of the browser in both cases.
On the other hand, in some rendering benchmarks (once the DOM has loaded and the page is actually rendering), Servo is much, much faster than other browsers[0].
We kind of do at this point. It renders reasonably well, faster on some workloads than existing browsers. The majority of work still to do involves chasing down rendering bugs, and building a shell around it. That's a lot of work, but it's the sort of work that isn't breaking new ground like the work with integrating JS and the DOM and a GC into Rust, it's regular boring work. (There's some exciting things going on - see WebRender - but they're mostly theoretically optional and the browser would work perfectly fine and performant if it had much of the same infrastructure as it has today.)
> By the way, network card driver can be written in LuaJIT (and perform well) too[1]. Shall we do it?
Lua's already used for some embedded development. Using LuaJIT as a network driver in some cases seems reasonable to me - especially if you were running it as a userspace process under a microkernel.