This vulnerability in libvpx is in boring setup code that runs literally once, and it wouldn't matter if it was 100x slower. Codecs have a lot of "glue" code h

This vulnerability in libvpx is in boring setup code that runs literally once, and it wouldn't matter if it was 100x slower. Codecs have a lot of "glue" code handling configuration, I/O, and other stuff besides their most performance sensitive bit-pushing loops. But this safe-or-fast dilemma has been mostly solved with Rust (and Wuffs). I am writing codecs in Rust. Rust has many zero-cost abstractions (high level wrappers that get inlined, and compiled for specific types and values you use them with, and it gets optimized as concrete low-level code). This allows writing a lot performance-sensitive code using safe Rust. For example, you don't get redundant bounds checks if you use iterators, and despite being high-level abstraction with chains of iterators and closures, they compile to simple loops, and may even get vectorized (even more so than C, thanks to Rust's stronger no-aliasing and immutability guarantees). When you need something more adventurous, you can dress it in a safe (compiler-verified) higher-level abstraction on top of minimal amount of unsafe code. Even though the underlying unsafe code is as unsafe as C, making a small component out of it helps to review/test/fuzz it in isolation against its interface, rather than test it as part of a complex algorithm.