Bend is a programming language designed to run code as fast as C on CPUs and CUDA on GPUs, while letting you define mathematical laws that the compiler enforces to prevent AI-generated code from breaking your app's core rules. You write laws in a LAWS.bend file, and the compiler demands proof that any code changes satisfy those rules before merging.

• The language compiles to single-core C speeds and parallelizes automatically across thousands of GPU cores without manual threading or locks.
• LAWS.bend lets you declare invariants (like "winning is impossible" or "array_set() never goes out of bounds") that the compiler mathematically verifies, blocking AI mistakes at commit time instead of catching them in production.
• The proof checker runs orders of magnitude faster than existing proof assistants—verifying files in under a second that would take minutes elsewhere—making formal verification practical for everyday development.

AWS introduced the Nitro Isolation Engine on its new M9g and M9gd Graviton5 instances and used Isabelle/HOL to prove that it enforces strict VM isolation. They modeled the engine in a subset of Rust (μRust), wrote Separation Logic specifications, and proved functional correctness, memory safety, and noninterference to guarantee confidentiality and integrity.

• AWS deployed a formally verified hypervisor component (Nitro Isolation Engine) into production commercial cloud infrastructure for the first time, on new M9g/M9gd Graviton5 instances.
• They produced 330,000 lines of machine-checked Isabelle/HOL proofs, matching seL4's verification scale, covering functional correctness, memory safety, and noninterference.
• The proof approach modeled the engine in a custom μRust subset (no traits/dynamic dispatch) with Separation Logic specs and a weakest-precondition calculus via their open-source AutoCorrode library.
• Every guest-state-touching operation must pass through this engine, which checks requests against the formal spec to mathematically guarantee VM confidentiality and integrity.

Martin Kleppmann discusses his journey from startups to academia, and the new edition of his book Designing Data-Intensive Applications. They cover trade-offs in modern infrastructure, cloud scalability, distributed system challenges, and emerging topics like formal verification and local-first software.

• Kleppmann rewrote and reorganized Designing Data-Intensive Applications' second edition to add consensus algorithm case studies and deeper cloud failure-handling coverage
• Cloud infrastructure has shifted the core scaling trade-offs from raw hardware capacity to network behavior and API guarantees
• Kleppmann is now researching local-first software algorithms for offline-first collaboration and cryptographic methods for supply-chain transparency that preserve pricing/manufacturing secrecy
• He predicts formal verification will become more important as AI-assisted coding introduces subtle bugs that are hard to catch otherwise

In this Pragmatic Engineer episode, Martin Kleppmann walks through updates in the second edition of Designing Data-Intensive Applications and shares how his LinkedIn experience shaped the book’s core concepts. He breaks down trade-offs in multi-region and cloud architectures, explains why replication still matters more than sharding, and predicts a rise in formal verification and local-first software.

• Second edition of DDIA cuts MapReduce coverage in favor of Spark and Flink, reflecting how the field has moved on
• Manual sharding has become rare thanks to bigger hardware and managed services, making replication the fault-tolerance skill every team now needs
• Kleppmann predicts LLMs will make formal verification mainstream by automating proof generation, shifting the bottleneck to human review
• Architecture decisions like multi-region or multi-cloud are business trade-offs between risk and cost, not universal best practices