Rust vs C vs Assembly programming languages - FFmpeg developer explains | Lex Fridman Podcast
An FFmpeg/VLC developer discusses the Rust programming language's strengths and limitations compared to C and assembly. While acknowledging Rust's memory safety benefits, he argues it falls short for real-world adoption due to interoperability challenges, the difficulty of rewrites, and the fact that inline assembly undermines Rust's security model entirely.
Summary
The speaker opens by comparing Rust to Esperanto and the Sinclair C5 electric vehicle — well-intentioned but overly utopian projects that fail to meet the practical bar of being 'as good as or better' than existing solutions. He notes that while memory safety is a worthy goal, Rust's community sometimes prioritizes self-importance over solving real-world problems. He points out that Rust still has only one compiler implementation and cannot randomly break ABI, setting a high bar it hasn't yet cleared for projects like FFmpeg.
Drawing on personal experience adding Rust modules to VLC and building his startup Kyber in Rust, the speaker concedes that Rust is 'a better C++ that cares about memory' and excels at memory ownership — making it excellent for greenfield projects, file parsing, and networking. However, he strongly cautions against the Rust community's instinct to rewrite existing codebases, explaining that reading and understanding existing code is an order of magnitude harder than writing new code. Developers who don't understand legacy wisdom often underestimate the effort required to reach 100% feature parity, getting stuck after the easy 80–90%.
The speaker raises a critical technical point specific to multimedia software: projects like H.264 decoders rely heavily on handwritten assembly for performance. Even if the C portions are rewritten in Rust for security, the inline assembly can jump anywhere in memory, completely destroying the security model Rust was meant to provide. He argues the real solution is 'secure assembly' — compile-time instrumentation of assembly code to prevent arbitrary memory jumps — rather than simply rewriting C in Rust.
Key Insights
- The speaker argues that Rust has an 'Esperanto vibe' — a utopian project where the community focuses too much on self-importance rather than meeting the practical requirement of being as good as or better than existing solutions like C.
- The speaker claims it is an order of magnitude easier to write code than to read it, which is the core reason developers instinctively want to rewrite codebases they don't understand — they skip the hard work of learning existing wisdom and business logic.
- The speaker argues that Rust rewrites inevitably stall because reaching 80–90% feature parity is relatively easy, but the final 10% takes 99% of the effort, echoing the Elon Musk quote that 'prototypes are easy.'
- The speaker identifies a fundamental flaw in applying Rust to multimedia software: even if the C code in a codec like H.264 is rewritten in Rust for memory safety, the handwritten assembly required for performance can jump anywhere in memory, completely nullifying Rust's security guarantees.
- The speaker proposes that the real solution for securing performance-critical software is 'secure assembly' — compile-time instrumentation that checks assembly code to ensure it does not jump to arbitrary memory locations — rather than relying solely on Rust rewrites.
Topics
Full transcript available for MurmurCast members
Sign Up to Access