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.
> I think it is important that these libraries get rewritten in Rust over time, starting with the most Web-facing code --- Harfbuzz and stb_image.
Text shaping is _hard_ and not something you want to NIH on.