Memory Safety Everywhere with Both Rust and Carbon
summary
Compares Rust’s two-state borrow model and trait-based workarounds with Carbon’s design choices aimed at C++ brownfield migration: alias set annotations to model allowed buffer aliasing, a richer mutability lattice including non‑exclusive mutable references, and support for separate compilation with API/impl files and overloads/templates to match C++ APIs. Proposes a borrow‑checker-like verifier, function/file-level strictness for unsafe markings, an optional permissive unsafe mode for legacy behavior, and a goal of one‑to‑one translation‑unit migration for incremental porting. Slides linked in uploader description.
AI-written summary · about
chapters (20)
- 0:00Introduction and background
- 1:47Memory safety and ecosystems
- 3:12Greenfield vs brownfield definitions
- 4:36Maximalist approach to memory safety
- 6:23Carbon’s role in brownfield migration
- 7:27Language design differences Rust vs Carbon
- 8:09Code organization in Rust and Carbon
- 13:33Type systems in Rust and Carbon
- 14:58Inheritance and complexity
- 15:40Function overloading in Carbon
- 16:44Generics and templates
- 17:26Safety design in Carbon
- 18:08Mutability and exclusivity models
- 20:13Real-world API migration challenges
- 23:45Rust’s structural API constraints
- 24:49Exclusivity and pointer invalidation
- 28:41Rust’s unsafe migration trade-offs
- 31:08Simplicity vs complexity trade-offs
- 32:13Collaborative path to memory safety
- 32:59Q&A session
related talks
17mFoundations for a Rust-Like Borrow Checker for C
35mLet’s Talk About Rust
01h 22mCompile-Time Borrow Checker with Stateful Metaprogramming
15mTranslating C to Safer Rust
01h 23mCarbon Language: An experimental successor to C++
39mRust, zig and carbon: Hype, hope or hell programming languages?
22mReconciling High-level Optimizations and Low-level Code in LLVM
01h 11mProgramming language memory models: Problems, solutions, and directions