There’s no escaping Rust, and the language is leaving its mark everywhere. This time around, Chrome has replaced its use of FreeType with Skrifa, a Rust-based replacement.
Skrifa is written in Rust, and created as a replacement for FreeType to make font processing in Chrome secure for all our users. Skifra takes advantage of Rust’s memory safety, and lets us iterate faster on font technology improvements in Chrome. Moving from FreeType to Skrifa allows us to be both agile and fearless when making changes to our font code. We now spend far less time fixing security bugs, resulting in faster updates, and better code quality.
↫ Dominik Röttsches, Rod Sheeter, and Chad Brokaw
The move to Skrifa is already complete, and it’s being used now by Chrome users on Linux, Android, and ChromeOS, and as a fallback for users on Windows and macOS. The reasons for this change are the same as they always are for replacing existing tools with new tools written in Rust: security. FreeType is a security risk for Chrome, and by replacing it with something written in a memory-safe language like Rust, Google was able to eliminate a whole slew of types of security issues.
To ensure rendering correctness, Google performed a ton of pixel comparison tests to compare FreeType output to Skrifa output. On top of that, Google is continuously running similar tests to ensure no quality degradation sneaks into Skrifa as time progresses.
Whether anyone likes Rust or not, the reality of the matter is that using Rust provides tangible benefits that reduce cost and lower security risks, and as such, its use will keep increasing, and tried and true tools will continue to be replaced by Rust counterparts.
“If it ain’t broke, don’t fix it”
But if it is. Fix it with Rust
Adurbe,
Haha, nice rebutal
Software has bugs. Despite what some developers think about their prowess, real world statistics show us both that software has bugs and that more that three-quarters of those bugs are going to be memory safety and / or concurrency issues. Anything that handles untrusted input that is written in a memory-unsafe language should be considered broken by design. Clearly, that is the thinking that Google is applying here.
“This library should not panic regardless of API misuse or use of corrupted/malicious font files. Please file an issue if this occurs.”
“Unsafe code is forbidden by a #![forbid(unsafe_code)] attribute in the root of the library.”
It is very clear that safety is the primary driver here and some languages simply do not offer a sufficient level of safety. There is no “#![forbid(unsafe_code)]” in C++.
The closest you can get to safe in C or C++ is battle-tested code that changes little. That is why Google says ” Skrifa allows us to be both agile and fearless”. No matter how good you are, you simply cannot move fast in a C++ code base and pretend that it is also secure.
I get that people are sick of rewrite everything in Rust.. In general, I am not a fan of total rewrites and so I am not always happy to see good code thrown away for a shiny new Rust version either. But there are certain areas where the characteristics of the language simply make it a better choice. This is one.