- firstly, the entire foundation, Rust, is itself an ambitious research project that solves many long-standing problems in the domain.
- Servo has, or has plans for, parallelism (combinations of task-, data-parallelism, SIMD, GPU) at every level of the stack.
- The entirety of CSS layout (one of the most difficult and important parts of the stack) is already parallelized, and it's fast.
- It puts all DOM objects in the JS heap, eliminating the nightmarish cross-heap reference counting that historically plagues browser architectures (this is part of Blink's "oilpan" architecture).
Does Gecko not already do this? Certainly Presto did, and (I believe) Trident does.
But to add another bit of research into the mix, and what I think is arguably the most important point:
- Builds on all the work around HTML(5) and CSS 2.1, both of which are the best part of a decade of work, both aiming to get browsers actually implementing to specifications, and specifying behaviour in sufficient detail (with minimal undefined behaviour) that a web page cannot easily distinguish two user agents. By actually specifying the web platform as it actually exists, it suddenly makes it far more practical for new browsers to enter the market (compared with the previous hellish situation of the hardest part of developing a browser being reverse-engineering existing browsers with sufficient marketshare that web developers ensure their web pages work in them). If this is shown to be viable, suddenly we have a truly open platform!
WebKit is similar, but without the cycle collector.
Single-threaded GC is nice because it doesn't have to stop any other threads in order to run; it also tends to reduce the size of the heap that must be scanned. For example, while script is collecting garbage, the layout and painting threads can run unimpeded. Of course, using a single-threaded GC in a multithreaded app means you have to be extremely careful in order to avoid the GC freeing things you don't want to be freed, and that is why it is seldom done. Our trick is to use the Rust type system to enforce that this is done correctly at compile time, which is something that is not possible in C++.
I doubt it, Trident's DOM is COM objects. Not only are the heaps separate, the DOM heap is page-independent and in the old days you could leak DOM objects for whole sessions if you created a circular reference between JS and DOM (because you set up an event handler closure for instance, the DOM element would reference the closure and the closure would close over the DOM element). There were tools (Drip and later sIEve) whose sole job was to wrap MSHTML, reload pages and detect objects remaining from the page you'd just left.
Also note, just because objects can have COM-accessible reference doesn't mean they always need to have one. It's quite possible they're just wrappers created on demand.
Don't need to, to be more precise.
E.g. Gecko renders every element on the page according to spec and spends 10seconds, while Servo renders like two in a millisecond (because it stubs the others).
To make stuff worse, Gecko will be super-optimized for browser benchmarks (like storing previous values of used functions to speed things like sin(x) ) that Servo will look way slower than Gecko, or maybe even Firefox 6.
Just after Brendan resigned, I read a comment somewhere to the effect of "I guess that's the end of Firefox OS". Um, no. A major project run by a company of 1,000 employees (and many volunteers) doesn't stop because one person left, even if that person is at the top. Especially when it's progressing well.
"A long time ago, in a galaxy far far away, I worked for a company called Sun Microsystems. One of the things I did there was to join a renegade band of engineers who were off in Palo Alto working on a technology that nobody within Sun could see any possible use for. That technology was of course Java."
Basically if you want to throw up a quick status display, it can do quite a bit.
So I thought I would update it to HTML4, maybe a bit of ECMA script for animations. Did a couple of runs at it and found most existing code had a bunch of stuff in it so that it could render "commonly occurring, but non-standard" HTML pages. In order to fit in a limited memory foot print system I was ripping things out left and right but stuff has more side effects than Cymbalta. So I tabled the project.
Starting from the premise of rendering "just the stuff we promise we can render" allows me to add stuff until I run out of memory and then stop.
I once heard one of our lead developers say that 80% of the code we wrote was to work around problems in everyone else's implementations. The DICOM format has a bunch of predefined fields and supports custom fields that manufacturers can use, but a lot of manufacturers would, for no reason I could figure out, use fields incorrectly a surprising amount of the time. They would store one of the most basic pieces of information in the wrong field, and then store that data nowhere, or put it in a custom field, or store it in the wrong format, etc.
Enough manufacturers doing 95% of things right and 5% of things wrong, making everyone else jump through hoops to handle their broken behaviour, and suddenly your code grows massively. Sure enough, we had to write an entire system for remapping fields from certain machines so that incoming data from broken implementations would be somehow magically coerced into being correct (either by simply copying data over to fields, or more advanced post-processing).
The less time browsers spend wondering what to do with inherently, irredeemably broken HTML, the faster they can render content which actually does work properly.
Unfortunately, that only works in controlled environments, like store kiosks, intranets, etc. Otherwise you end up choking on the 95% of the content which is only 5% broken.
<script type="text/x-rust" src="foo.rs">
Native Rust support would be far better.
I've followed Harmony / ES6 for like 7 years now.
Don't hold your breath. (And I know that you can get lots of these features with special switches in Chrome, FF etc. Also know about Traceur. I mean don't hold your breath about having it released and available all-around for real web work, frameworks updated for it, etc).
 The caveat here is that we have to support IE8 (for now at least) which the Traceur runtime doesn't support, so there are a few features we cannot use (yet).
I'm not sure about the runtime, but I think I remember it doing some (very basic) feature detection while browsing through the generated code during a debugging session.
EDIT: Frankly, I think it would probably be a good idea to polyfill all browsers until they all really implement the ES6 spec.
You mentioned things like templates in C++ - those will be an issue in asm.js just as they are in a native build, no more and no less.
I'm not sure you'd want to send Rust source code - you'd need to wait for it to compile on the other side. (Rust is designed for many things, but fast compilation is not a primary goal.) Most likely you'd want to build it ahead of time on the server, just like C++, but then I'm not sure there would be a size advantage to Rust.
Thanks for the offer of help. Unfortunately I can't send our code, but I just talked to our guy working on emscripten and he said he's already been in touch (though not about code size yet). https://groups.google.com/d/msg/emscripten-discuss/n1qfKPPAy...
My impression of emscripten code size might be out of date, I know that development on asm.js has been pretty rapid.
After all, the point is to generate efficient code, so a solution that simply disregards most optimizations isn't an option; and most of the type system is likely unavoidable and/or critical to the optimizer.
By contrast, asm.js is fairly simple: All the heavy lifting of compiling has mostly been done - the remaining JS was chosen so that it fairly straightforwardly represents assembler instructions. Decisions about types and what that means for semantics (and safety) have been done, inlining, code rearranging etc. - that's all largely done. In a way, asm.js is assembler with a weird syntax and environment. I really doubt you'd ever get something like Rust (or really most any other statically compiled language) to ever compile as fast, given comparable resources.
Out of interest, I did a search, and there does seem to be a (depreciated) Rust REPL.
The biggest impetus for Servo at the moment is that it's researching the biggest wins to be gained from concurrency and parallelism in browser engines, thereby guiding efforts to tack such things onto Gecko.
Does anyone care to explain how this would work? If you used OpenSSL from Rust you would still be vulnerable to Heartbleed. Or am I missing something?
Also they say:
>> Many kinds of browser security bugs, such as the recent Heartbleed vulnerability, are prevented automatically by the Rust compiler.
Are they referencing reverse heartbleed here? Browsers themselves were not vulnerable to heartbleed, I don't even this they were vulnerable to reverse heartbleed.
There is no way Servo would have prevented the heartbleed bug, no browser could have, I feel like that sentence has no place in this blog post.
The point I was trying to make is that you can't make that kind of mistake in the safe Rust language. You will fail a bounds check even if you decide to trust client provided lengths.
"Servo protects you from that really scary thing the internet has been atwitter with for the past week whereas other browsers leave you high and dry"
I know that is not what you said and probably not what you meant but it just seemed like an odd way to word IMHO.
Clients could have been vulnerable to Heartbleed. Feel free to correct me on this, but I believe the only reason they weren't is that Chrome uses OpenSSL compiled without the heartbeat feature, and Firefox uses NSS.
If you called OpenSSL from Rust, it would be the same as calling C from Java.
Gist of issue, Rust's static type checker would prevent bugs that caused HeartBleed.
I believe its more a case that it would have been a run-time error due to Rust's automatic bounds checking. This is because Rust uses 'fat pointers' for strings, vectors and slices that include bounds information rather than a single, raw pointer like in C. Do note there are unsafe ways around bounds checking, but these are restricted to unsafe blocks, which makes them easier to audit.
"It is designed to be more memory safe (far and away the #1 cause of browser engine security bugs!)"
As an example, we used to use Netsurf's C library for CSS stuff, but now we have our own parser and style system written in 100% Rust.
I'm not entirely sure this is a correct claim, unless you mean 'system calls are implemented by the kernel, which is written in C.'
While it's true that FFI in Rust is really good, most things (notably, _not_ crypto) are just straight-up written in Rust.
Edit: Servo's src/support directory is a good example of my general sense that large Rust projects still tend to rely on a good deal of C libraries:
And a 2014 Brainstorm thread with similar ideas: https://groups.google.com/a/chromium.org/d/msg/blink-dev/Z5O...