More specifically, a brand new layout engine for Firefox, to eventually replace Gecko, with better concurrency and safety enabled by Rust. Firefox will still use the same Javascript engine.
I'm actually not sure what version of Rust the Servo folk are using... in which case the Rust you're reading may be very different from the language's current iteration. I believe work on Servo started immediately after 0.2 was released, back in March. 0.3 ought to be out sometime this week. And I still wouldn't exactly recommend learning either version, because most of the tutorials and docs still refer to 0.1. :P If you want help learning or want to help out, the devs hang out in #rust on moznet during California working hours.
We're using the bleeding edge master builds of Rust. Our work on Servo informs the direction we want to take Rust, and vice versa. Servo has been really valuable to help us determine whether the language features really work out in practice.
For someone who knows Rails and front end web development (and a bit of Java and a touch of C++), what could I offer to Servo? Learning Rust and helping would be fun, but would such novice to Rust be welcome to the project?
The language was only officially unveiled in 2010, so I don't think you will have too many problems with impatient rust greybeards pouring scorn on the new fledgling whippersnappers yet.
That ignores what Servo actually is. The entire point of it is that it's written from the ground up in a modern, typesafe language. External libs take away from that and add security and performance concerns.
Fair enough. I appreciate that bold ambition, and I realize it's an R&D project :). It just has a little bad negative aftertaste to it in this context, considering that Harfbuzz has been a really good example of a body of code that solves a hard problem and has been collaborated on and adopted by many different parties. Going NIH on it, even with noble intent and explicit technical reasons, just feels like a step backward, and like trying to do too many things at once.
I guess what it comes down to is whether what Servo is justifies that lack of pragmatism: That's what it'll have to prove.
FWIW, there are two Harfbuzzes: the old one that is derived from Qt code that many people have collaborated and hammered on over the years, and the new one that Mozilla uses that was rewritten from scratch by one person. The new one is likely better-written overall (the author generally knows what he's doing), but it's not really true that Harfbuzz (as Mozilla uses it) has been collaborated on by many parties or has had as much (or any) security analysis.
(I worked on relevant pieces of Chrome, which has has a bunch of security issues due to bugs in the older, presumably more vetted, Harfbuzz, so I don't have a lot of confidence of code in this area. Lots of indexing into arrays.)
JPEG is a good benchmark because it is a bottleneck, heavily optimised with SIMD, and still amenable to some parallelisation. That doesn't apply to text layout.
Daeken's point below is spot on, but I thought I'd add that, if we don't have the manpower to rewrite everything in a safe language, we can go out of process and sandbox like Chromium does. (In fact, the plan is to sandbox even the safe code.) Of course, that's plan B; plan A is to parallelize the entire stack, top to bottom.
Rust is interesting to deal with some hard problems keeping a multicore program safe and efficient, but I'm sure sandboxing will provide a better tradeoff for a lot of things (and as sho_hn points out, Harfbuzz correctly embeds a lot of domain knowledge from multiple cultures). C can be locked down pretty tight, see for example ZeroVM which restricts it to pure functional code.
Text shaping is hard? How about a browser? If these guys think they've got something innovative, more power to them. We got this comment a lot back when we started Chrome, but fortunately we didn't let it stop us :-)
Yes, browsers are hard!* That was sort of the point: If you're trying to crack a problem like that, you might not want to also try to solve text shaping on the side, because you may not have the time to do it properly. There's a lot more out there than English, and OpenType can do quite a lot.
* = I hail from KDE, and am good friends with some of the people who originally made the browser engine you're using today in Chrome :).
Like I said, the success of the project doesn't depend on the feasibility of rewriting HarfBuzz. We're quite pragmatic about using external libraries; in fact, Rust's FFI is the best FFI I've ever used in any non-C/C++ language. Robert's point is simply that the end result will be better if we can make a memory-safe, parallel HarfBuzz along the way, written in a language that improves programmer productivity.
Interesting. This was written before Google released Chrome. How parallel is Chrome, exactly, compared to the kind of browser described in this blog post?
WebKit, like all engines, is fundamentally single-threaded. Of course, there can be some parallelism added to specific components--in the case of Chrome, multiple tabs (to be more accurate, multiple origins) can execute in parallel--but there's a scalability limit to how far a single-threaded design can take you.
I think multiple "units of related browsing context" [1] would be more accurate; unless I am wrong Chrome uses at most one process per event loop and has one event loop for each set of browsing contexts that can reach each other via the DOM. This means that e.g. an alert in tab A will block scripts in tab B if B.opener == A.
AFAICT IE has a somewhat different design; it seems to really be much closer to "one process per tab", which presumably means that they incur some IPC overhead when different tabs in the same unit of related browsing context have to communicate.
You're somewhat wrong. Chrome will put browsing contexts that normally can't reach each other via the DOM on the same event loop (and in the same process) if it decides it's got too many renderer processes spawned already. Once it does that, they can try to reach each other via the DOM if they have window names.
Oh, so 1:1 between processes and event loops? Doesn't that mean that something blocking in one tab (alert(), sync XHR) might will block tasks in any entirely unrelated tab that just happens to share a process/event loop? That seems rather unexpected.
I can't speak to the exact event loop behavior; I haven't tested it.
Even if you have only one main event loop per process, spinning nested event loops (e.g. the way Firefox does for alert and sync XHR) would let you do things in one tab while another is blocked on an alert or whatnot. I just don't know whether Chrome does that.
It's funny how the first comment is about browsers lacking a "super-mega-fast-quick JS engine". I bet that was one happy Chrome user when it first came out :)
http://www.2ality.com/2012/02/servo.html
Tl;dr: A brand new browser, implemented with a language called Rust, aims to be small and good at utilizing CPU cores.