Chris Lattner is one of the most influential software engineers of the past two decades — he created LLVM (the compiler infrastructure behind Swift, Rust, and many other languages), the Swift programming language at Apple, and now leads Modular, building Mojo, a new programming language designed for high-performance AI engineering. This episode traces his entire career arc and the philosophy behind his work.
The early compiler landscape and why Chris built LLVM
In the late 1980s and early 1990s, every hardware vendor built their own C/C++ compiler, leading to massive incompatibility — different bugs, missing features, and a fragmented ecosystem held together by fragile build tools like autoconf.
GCC emerged in the 1990s as a unifying force: free, open source, and adopted widely by the Linux community. It cleaned up the mess but was architecturally old — designed as a monolithic batch compiler that couldn’t do JIT compilation, cross-file optimization, or modular code generation.
Around 2000, as a university student studying compilers, Chris started LLVM as a research project to explore modern compiler design. It began as a code generation system that plugged into GCC’s parser, focused on optimization and targeting multiple architectures.
LLVM was open sourced with a small community of compiler enthusiasts. Chris treated it as open development — welcoming contributors, answering questions, and slowly growing adoption through regular six-month releases.
How LLVM replaced GCC at Apple
When Chris graduated, Apple recruited him specifically because their engineering leadership was frustrated with GCC — it was the foundation of all Objective-C compilation, but was hard to extend, slow to improve, and the GCC community was uncooperative with Apple’s needs.
Chris joined Apple in 2005 with one other engineer and a mandate to explore LLVM, but no guarantee of long-term support. Management made it clear: if LLVM wasn’t in a real product within a year, he’d be reassigned.
The first production use was for OpenGL shader compilation — a small JIT use case that proved LLVM could deliver real business value. This unlocked further investment.
Over the next five years, Chris’s team incrementally replaced Apple’s entire developer toolchain: they built Clang (a new C/C++/Objective-C frontend), replaced the debugger, and integrated everything into Xcode. Each six months brought a new capability that justified more resources.
By 2010, LLVM powered the first 64-bit iPhone (iPhone 5s), shipping in production before ARM’s own chips were ready for testing. The industry was skeptical that 64-bit phones made sense, but Apple’s performance results were stunning.
The combination of top-down executive support (frustration with GCC) and bottom-up delivery of compounding value let Chris grow from an individual contributor to senior director, eventually replacing all of Apple’s compiler and debugger technology.
LLVM’s success snowballed: Cray used it for supercomputers, Google adopted it in 2010, and eventually chipmakers like Intel and ARM canceled their internal compilers to switch to LLVM. Today it has thousands of contributors.
The origin story of Swift
After finishing the Clang/LLVM toolchain in 2010, Chris was demotivated by the complexity of C++ and started wondering if a better language was possible. He began working on Swift in secret — nights and weekends — without asking permission.
He surveyed many languages: Java, Haskell, OCaml, Go, TypeScript, Dart, Rust, and JavaScript. His key insight was that successful languages scale across domains — JavaScript was designed for click handlers but now runs web servers. He wanted a language that could scale from embedded systems to high-level scripting.
He was drawn to Objective-C’s combination of a high-level object model (Smalltalk-inspired) with C for performance, but saw that the two-language split was unnecessary. Swift would unify them into one language with memory safety, type inference, and modern syntax.
For the first 1.5 years, it was just Chris working alone. When he told management, they were skeptical — “Objective-C made the iPhone successful, why change?” He was allowed to tell a few team members but got no official resources.
Over the next two years, Chris incrementally pulled Objective-C closer to Swift by adding features like ARC (automatic reference counting), modules, and literals. This reduced the eventual migration pain.
By year three, with a team of ~250 people under him running Xcode and developer tools, executive leadership approved Swift as a formal project. The final year was a massive push to finish the language, integrate with iOS SDK, Xcode, and the debugger.
Swift launched at WWDC 2014 as version 1.0. Chris’s key learning: don’t call something 1.0 until it’s truly ready. Swift 1.0 was rough — Xcode lacked refactoring support, debugging was painful, and the compiler had issues like “expression too complex to type check.”
Apple was transparent with the community: they warned that source code would break between versions. This was painful but necessary — Swift 2 and 3 broke the language to fix fundamental issues, and only at Swift 3 did they commit to stability.
Swift Playgrounds and REPL were launched alongside the language, driven by a desire to make coding accessible and modern. The documentation team wrote “The Swift Programming Book” for launch.
Community adoption followed a classic technology diffusion S-curve: early adopters jumped in immediately, but many experienced Objective-C developers resisted because their expertise was being invalidated. It took years — and SwiftUI — to move the long tail.
Chris’s proudest moments came from people who told him they became app developers because of Swift — they couldn’t handle Objective-C’s pointers and square brackets, but Swift made it accessible. He sees the same gatekeeping problem today with CUDA and GPU programming.
What Chris would do differently with Swift
He acknowledges that early Swift suffered from his own inexperience — he’d never built a language before, and features were added faster than the architecture could absorb them. The internals didn’t line up cleanly, leading to emergent complexity that developers feel today (too many keywords, inconsistent behavior).
He compares this to C++‘s legacy: int and float are hardcoded into the language rather than being library types, a decision inherited from C that can’t be undone. Swift fixed this, but accumulated its own technical debt.
He believes the right call was to break the language early (Swift 1→2→3) rather than freezing the mistakes. The pain was worth it.
AI learnings from Tesla and Google
In 2016, Chris fell in love with AI when Apple’s Photos app could detect cats and dogs — something he knew he couldn’t write algorithmically. This led him to Tesla (self-driving, TensorFlow) and then Google Brain.
At Google, he owned the bottom of TensorFlow — the CPU/GPU/TPU runtime layer — and scaled the TPU software platform. He learned that the entire AI ecosystem is heavily dependent on Nvidia’s CUDA, a 20-year-old C++-based platform.
Google built XLA as a compiler-based alternative to hand-written kernels, enabling auto-fusion and automatic kernel synthesis. This was powerful but couldn’t keep up with the pace of AI research — when new algorithms like flash attention emerged, compiler engineers couldn’t implement them fast enough.
Chris observed that kernel engineers, compiler engineers, and AI researchers think differently and rarely overlap. This talent bottleneck meant that every new chip required massive manual effort, and the best engineers were always firefighting production issues rather than building foundational technology.
He concluded that the AI software stack needed a “LLVM moment” — a modular, reusable infrastructure that chipmakers could plug into rather than building everything from scratch.
SiFive and the hardware side
Chris joined SiFive, a company building RISC-V hardware, to learn the hardware side of the boundary — physical design, chip verification, IP licensing, and the business model of hardware.
He worked on building an AI chip/IP and discovered the same problem: there’s no off-the-shelf software stack for AI accelerators. Every vendor (Google with TPUs, Apple with Metal/MLX, AMD with ROCm) builds their own verticalized stack with minimal code sharing.
The vision behind Modular and Mojo
Modular was founded on the observation that the AI software ecosystem is where compilers were before GCC — every chipmaker builds everything from scratch, and the cost is enormous. Companies like Anthropic have written about deploying the same models three times (CUDA, TPU, Trainium) with bugs, quality issues, and outages from the divergence.
Chris’s bet is a two-level stack:
Mojo: a new programming language in the Python family that gives developers the power of compilers without requiring them to be compiler engineers. It has a much simpler, more predictable compiler than Swift/Rust, with control explicitly in the programmer’s hands.
A compiler framework (like LLVM for AI) that chipmakers can target to get a full AI software stack without building everything from scratch.
Mojo’s key technical ideas:
Python-compatible syntax for readability and familiarity, but with a modern compiler that replaces the Python interpreter entirely.
Powerful metaprogramming (inspired by Zig) that unifies the program and the meta-program — you can run the same code at compile time and runtime, debug it with standard tools, and build compile-time transformations naturally.
Explicit control over hardware features: SIMD, bfloat16, compressed floating-point formats, memory allocation — no “sufficiently smart compiler” magic that creates unpredictable performance.
Library-level vectorization and other optimizations that you opt into explicitly, avoiding the leaky abstraction problem where a small code change causes a 4x slowdown because the compiler’s pattern matching broke.
Seamless Python interop without bindings — you can extend slow Python modules with Mojo directly, similar to how Swift and Objective-C interoperate.
The goal is to break the gatekeeping in GPU/AI programming. Chris shares the story of a geneticist who made his DNA sequencing code 100x faster on CPU with Mojo, then got it running on a GPU in an afternoon and became a “GPU programmer.”
Modular as a company
Modular is ~four years old with ~140 people — an unusually large and well-funded team for a startup, reflecting the depth of the problem.
They’ve enabled seven different GPU architectures from three vendors: Nvidia (Hopper, Blackwell), AMD (MI300, MI325, MI355, plus consumer GPUs), and Apple GPUs (in beta).
Mojo 1.0 is targeted for early summer 2026, and the team is being deliberate about getting it right — learning from Swift’s premature 1.0.
Their commercial model is a cloud platform for enterprises that want hardware optionality (avoiding vendor lock-in) and reliable, scalable AI infrastructure. Mojo itself is open source and not the primary monetization vehicle.
Chris predicts 2026 will see a proliferation of silicon from many vendors, and Modular wants to be the software layer that lets customers scale across all of it without rewriting three times.
How Chris and his team use AI coding tools
The Modular team actively uses AI coding tools (Claude Code, Cursor, and others). Chris uses Cursor as his daily driver and estimates ~10% productivity gain on mechanical rewrites — meaningful for a senior engineer.
For prototyping and PMs building wireframe models, the tools are transformative — enabling 10x output for people who wouldn’t otherwise build certain things.
For production coding, Chris is more cautious: he’s seen agents grind through millions of tokens without solving problems that a human would have solved faster. He emphasizes using AI as a human assist, not a human replacement.
His main concern with “vibe coding” for production systems: if you don’t understand the architecture, you can’t maintain or evolve it. AI tools tend to duplicate code across places, creating maintenance nightmares. He stresses the importance of curated architecture and human review.
On hiring: Modular hires both deep specialists (compiler engineers, GPU experts) and early-career engineers. For junior candidates, he values intellectual curiosity, fearlessness, willingness to work hard, and open-source contributions as proof of teamwork ability. He lets candidates use AI tools in interviews to approximate real-world conditions.
Should programming languages be designed for LLMs?
Chris firmly says no. The key thing is reading code, not writing it — and AI has made writing code trivially easy. What matters is expressivity (can you express the full power of the hardware?) and readability (can humans understand and maintain the code?).
He thinks the intersection of expressivity and readability is what matters. Python syntax is a good foundation because it’s widely known and readable. Mojo embraces Python’s syntax and fixes the implementation.
He notes that LLMs are actually an amazing way to learn a new language, and open-sourcing a large codebase (Modular has ~700,000 lines of Mojo) is the most important thing for LLM-based coding — it gives the models a massive corpus to learn from.
On error messages: he thinks the question “should we make better error messages for agents?” is backwards — just make good error messages for humans. What’s good for humans is good for agents.
Why compilers are cool and how to get started
Chris loves compilers because they reflect real software development: you build incrementally (lexer → parser → type checker → code generator), each layer building on the last, and mistakes compound so you learn to fix them. Unlike most CS classes where you build something, throw it away, and start over, a compiler project teaches iterative architecture.
Resources for learning: the LLVM Kaleidoscope tutorial (which Chris wrote 15+ years ago), the Rust community’s compiler-focused projects, and various books and courses. He encourages more people to enter the field — there are good jobs and the world needs more compiler engineers.
