From Swift to Mojo and high-performance AI Engineering with Chris Lattner

Summary

The Pragmatic Engineer: "From Swift to Mojo and High-Performance AI Engineering with Chris Lattner"

Date: November 5, 2025
Host: Gergely Orosz
Guest: Chris Lattner (Creator of LLVM, Swift, and Mojo)

---

Episode Overview

This episode features an in-depth conversation with Chris Lattner, one of the most influential figures in modern programming languages and compiler technologies. The discussion spans Chris's unique journey: from creating LLVM (the bedrock of many compilers), to his behind-the-scenes work on Swift at Apple, and his current efforts building the new Mojo programming language for high-performance AI engineering at Modular. Chris delves into lessons learned, how software and hardware intersect, strategies for introducing sweeping changes at large companies, and the future of programming in an AI-driven world. Engineers and tech leaders will find practical wisdom, vivid anecdotes, and candid takes on building impactful engineering projects from the ground up.

---

Key Discussion Points & Insights

1. Early Industry Context: The Compiler Landscape

• State of Compilers in the Early 2000s

  • In the 1980s and 90s, each hardware vendor built their own proprietary C compiler, leading to widespread incompatibility and confusion.
  • "It was a gigantic mess... GCC came on the scene, really in the 90s, and cleaned up that mess... It became the standardized thing." — Chris Lattner [03:19]
  • GCC’s open source nature helped propel Linux and standardized compiler environments.
  • However, GCC was inflexible, monolithic, and lacked modern features like JIT and cross-file optimization.

• Birth of LLVM

  • Chris started LLVM as a university project to improve on GCC's limitations and as a means to learn about compiler design.
  • LLVM introduced modularity, flexibility, and new capabilities — such as JIT compilation and targeting multiple architectures.
  • "Compilers are cool, even today!" — Chris Lattner [06:09]
  • LLVM's adoption within Apple was gradual and pragmatic: first for internal uses and experimenting, eventually moving to core product tools.

2. Driving Strategic Tech Change Inside Big Tech

• Winning Organizational Support

  • Progress depended on both top-down executive support and bottom-up grassroots wins:
  • "It wasn't one thing, it was just a lot of hard work... every six months we'd have a new thing... I became known as somebody who would get things done." — Chris Lattner [14:28]
  • Gradually, LLVM replaced all of Apple’s internal compiler/codegen/debugger infrastructure, culminating in industry-defining moments such as enabling the first 64-bit iPhone.

• Convincing a Closed Company to Open Source Critical Tools

  • LLVM/Clang: “We didn’t really ask too many people for permission, we just kind of did it. And so that was the easy one. The hard one was Swift.” — Chris Lattner [20:05]
  • Strategic stealth, clear technical impact, and persistence allowed these projects to eventually get green-lit despite initial resistance.

3. The Genesis and Evolution of Swift

• From Nights-and-Weekends Project to a Shipping Language

  • Swift started around 2010 as a secret side project by Chris to address Objective-C’s limitations, particularly around safety and modernity.
  • Borrowed ideas from a wide survey of languages (e.g., OCaml, Haskell, Go, TypeScript).
  • "The first year and a half it was literally just me working on it... didn't ask permission, just started fiddling around, seeing what could be done that would be better." — Chris Lattner [00:00]

• Design Philosophy & Challenges

  • Focus: memory safety, scalability from embedded to high-level scripting, and leveraging best ideas across the language space.
  • “The initial ideas of Swift was really about saying, how do we build a scalable language and how do we pull together the best ideas, shamelessly, you know, borrowing ideas from different places.” — Chris Lattner [23:20]
  • Transition from secret to official project involved slow, internal socialization and incremental migration of features from Swift prototypes into Objective-C.

• Painful but Necessary Launch

  • Swift 1.0 shipped in 2014, but with known rough edges; Chris’s team was explicit about expected source-breaking changes and instability.
  • “We told people: we will help you, but expect code breakage. And I’m glad we did that.” — Chris Lattner [34:04]
  • Many in the Apple developer community were excited but wary, with significant internal debate over Objective-C vs. Swift for production use.
  • Adoption required nudging both early adopters and skeptics, with SwiftUI later serving as a killer feature for late migration.

• Reflection on Mistakes and Learnings

  • Chris candidly revisits hasty architectural decisions, feature creep, early technical debt, and the need to iterate at the language level.
  • "Early Swift... I didn’t know what I was doing. I’d never done it before. I’d built a C compiler which had a spec... and so a lot of the ideas going into it were new... That’s my fault." — Chris Lattner [42:59]
  • The transition to Swift 3.0 represented stabilizing and cleaning up the language.

4. The Path to AI: Tesla, Google, Modular, and Mojo

• Falling in Love with AI (2016+)

  • Sparked by applied AI (image recognition in the Photos app), Chris joined Tesla and then Google to work on deep learning infrastructure, especially for new AI chips (TPUs).
  • Led efforts to scale TensorFlow’s support for CPUs, GPUs, TPUs, and built foundational systems like MLIR.

• Identifying the Modern AI Software Stack Problem

  • At Google and Sci-Fi, Chris saw the pain of hardware-vendor-specific vertical stacks, causing massive duplication, bug-prone kernels, and inflexibility.
  • "Before gcc, every chip maker had to build their own software stack. That's literally the shape of AI software today... you share very low code." — Chris Lattner [53:16]
  • Modular’s vision: Build the LLVM for AI — a unified, extensible software stack (including a new language: Mojo) that allows targeting multiple hardware vendors efficiently.

• Mojo: Design, Principles, and Uniqueness

  • Mojo merges Python familiarity with scalable, high-performance semantics and a powerful, unified metaprogramming system (inspired by Zig, but modernized).
  • "Mojo is a member of the Python family, so it's super familiar, easy to learn... One of the simplest things to do with Mojo is to extend an existing Python module. No bindings—just like Swift and Objective-C." — Chris Lattner [69:44]
  • Explicit focus on giving performance control back to developers (e.g., vectorization, hardware features) and not hiding magic heuristics in the compiler.
  • Mojo’s design lets programmers (not just compiler experts) build high-performance, portable, and easily readable code for CPUs, GPUs, and future accelerators.
  • “A lot of what makes Mojo really special is it takes power out of the compiler and gives it to you as a developer. Because it turns out a lot of people can write code, they can’t necessarily write compilers.” — Chris Lattner [61:23]

• Current Progress and Next Steps for Modular/Mojo

  • Modular’s team: ~140 engineers, supporting multiple architectures across Nvidia, AMD, and Apple.
  • Mojo 1.0 is targeted for early summer next year (2026), incorporating lessons from Swift’s bumpy 1.0.
  • Open source is central; hundreds of thousands of lines available for AI tools and LLM training.
  • "We're still at the beginning and every year of our journey is just another epoch of new things to build and learn and grow and develop into this." — Chris Lattner [78:40]

5. Programming in the Age of AI: Humans & LLMs

• AI Coding Tools in Engineering at Modular

  • AI coding assistants (e.g., Claude, Cursor) are already boosting productivity, especially for mechanical or prototyping tasks.
  • For advanced engineers, the net productivity boost is meaningful (around 10%), but for prototyping or those less expert, it can be transformative.
  • "For me... I still code. I use Cursor as my daily driver right now. And so I feel like it's a good 10% productivity [boost]..." — Chris Lattner [79:43]
  • Risks: “Vibe coding” (blindly accepting LLM-generated code) can rot architecture and introduce maintainability problems. Human review and understanding remain key for production code.

• Should We Build Languages for LLMs?

  • Chris is clear: languages should prioritize human readability and expressivity, not just optimize for AI agents.
  • "I don’t think that optimizing for the LLM is the right thing to do at all... The important thing is reading the code. Always has been, by the way. Code is read more often than it's written... Writing the code is actually not the key thing to me, it's about reading it." — Chris Lattner [86:12 - 86:21]
  • Open source, concise syntax (like Python), great error messages, and high expressivity make both human and AI use easier and more effective.

6. Careers: Advice, Hiring, and Learning Compilers

• Engineering Hiring at Modular

  • The team recruits both seasoned specialists (e.g., GPU experts, compiler veterans) and fearless early-career engineers, including new graduates.
  • Curiosity, willingness to tackle unknowns, and open-source contributions are highly valued.
  • "I love to see people that are really hungry, have not given up, and just said, AI will do everything for me. They're intellectually curious, willing to work hard, and they're fearless... Open source contribution is a simple way to prove you can also work with a team." — Chris Lattner [83:43]

• Getting Started with Compilers

  • Compilers offer real-world programming experience: layering, correcting mistakes, and cumulative learning.
  • Start with standard tutorials, e.g., LLVM’s Kaleidoscope, or Rust’s compiler ecosystem.
  • "Compilers don't get the credit they deserve... There's a lot of really good jobs in compilers. I really do encourage people to do it because we need more folks in this field." — Chris Lattner [90:47]

---

Notable Quotes & Memorable Moments

| Timestamp | Quote | Speaker | |---|---|---| | 00:00 | “I just started again, nights and weekends. Didn’t ask permission, just started fiddling around, seeing what could be done that would be better.” | Chris Lattner | | 14:28 | “It wasn't one thing, it was just a lot of hard work and it was a lot of fun because we were able to... get things done, you had an amazing platform in which to work.” | Chris Lattner | | 23:20 | "How do we build a scalable language and how do we pull together the best ideas shamelessly, you know, borrowing ideas from different places." | Chris Lattner | | 34:04 | "We told people: we will help you, but expect code breakage. And I’m glad we did that." | Chris Lattner | | 42:59 | "Early Swift... I didn’t know what I was doing. I’d never done it before... and so a lot of the ideas going into it were new... That’s my fault." | Chris Lattner | | 53:16 | "Before gcc, every chip maker had to build their own software stack. That's literally the shape of AI software today..." | Chris Lattner | | 61:23 | “A lot of what makes Mojo really special is it takes power out of the compiler and gives it to you as a developer. Because a lot of people can write code, they can’t necessarily write compilers.” | Chris Lattner | | 69:44 | “Mojo is a member of the Python family, so it's super familiar, easy to learn... One of the simplest things to do with Mojo is extend an existing Python module. No bindings.” | Chris Lattner | | 86:12 | "I don't think that optimizing for the LLM is the right thing to do at all... The important thing is reading the code. Always has been." | Chris Lattner |

---

Segment Timestamps

• 00:00 – 08:12: Early context, GCC’s dominance, birth of LLVM
• 08:12 – 16:22: Differences between GCC/LLVM, early open source journey
• 16:22 – 20:19: Driving change at Apple, open sourcing critical infrastructure
• 20:19 – 34:33: The Swift backstory: inception, design, “secret” development, cultural challenges
• 34:33 – 45:30: Swift's launch, developer adoption, and lessons learned
• 45:30 – 51:13: Iteration in language/compiler design, the importance of starting fresh, technical debt
• 51:13 – 55:50: From Apple to Tesla, Google, and Sci-Fi—AI stack realities
• 55:50 – 61:23: Modular’s founding, the rationale behind Mojo
• 61:23 – 74:32: Mojo’s design, empowering more programmers, taking compiler power to the user, code-portability
• 74:32 – 79:17: Modular’s progress, hiring, company culture, and ecosystem
• 79:17 – 88:41: AI tools in engineering, LLMs, language design for AIs, open source and future direction
• 88:41 – end: Advice for aspiring compiler engineers, how to get started, compilers as a practical field

---

Conclusion

Chris Lattner’s journey is a testament to persistence, curiosity, and the impact of building foundational tools that empower other builders. His approach—start small, iterate fast, welcome change, and bring as many people along the learning curve as possible—emerges as a playbook for both software engineering leaders and ambitious individual contributors. Whether it’s rethinking programming languages for safety and scalability (Swift), or making cutting-edge AI accessible and performant for all (Mojo), Chris’s work continues to shape the direction of how software (and now, AI) is built.

---

For more episodes and engineering deep-dives: newsletter.pragmaticengineer.com

This summary skips sponsor reads and non-content segments, focusing on core technical and experiential discussions.

Transcript

[Chris Lattner]

And so I just started again, nights and weekends. Didn't ask permission, just started fiddling around, seeing what could be done that would be better. The first year and a half it was literally just me working nights and weekends and I had a day job and I was managing a big team and a lot of stuff going on.

[Podcast Host 1]

Hold on.

[Podcast Host 2]

So at this point, yeah, you were.

[Chris Lattner]

Already second level manager or something and had a team of 40 people.

[Podcast Host 1]

Wow.

[Chris Lattner]

Running a lot of very interesting and very fun stuff.

[Podcast Host 2]

You're good at juggling stuff.

[Chris Lattner]

This is a passion project. I'm also a fairly good programmer, so that helps.

[Podcast Host 2]

How do you go from this blank canvas to like, okay, here's what I think the language will be.

[Chris Lattner]

I start from a lot of blank canvases across my career, right? So llvm, Blank Canvas, mlir later, Blank Canvas, moj, Swift. Many of the systems I build are blank canvas projects.

[Podcast Host 2]

Do you think there is any logic in having a new language that is designed to make it easy for LLMs to code with?

[Chris Lattner]

So I often get asked, given the AI is writing all the code, why are you building a programming language? Which is another way of asking the same question, maybe a little bit more aggro. And so to me, I don't think that optimizing for the LLM is the right thing to do at all. Because the important thing is Chris Laffner.

[Podcast Host 1]

Created some of the most influential programming language and compile technologies of the past 20 years. He is a creator of LLVM used by languages like Swift, Ruft and C, created the Swift programming language, worked on TensorFlow, and now works on the Mojo programming language. In this conversation, we cover the original story of LLVM and how Chris managed to convince Apple to move all major Apple dev tools over to support this new technology. How Chris created Swift at Apple, including how we worked on this new language in secrecy for a year and a half, and why Mojo is a language Chris expects to help build efficient AI programs easier and faster. How Chris uses AI tools and what productivity improvements he sees as a very experienced programmer and many more. If you'd like to understand how a truly standout software engineer like Chris thinks and gets things done, and how he's designing a language that could be a very important part of AI engineering, then this episode is for you. This podcast episode is presented by statsig, the unified platform for flags, analytics, experiments and more. Check out the show Notes to learn more about them and our other seasoned sponsor.

[Podcast Host 2]

So, Chris, welcome to the podcast.

[Chris Lattner]

Well, thank you for having me.

[Podcast Host 2]

It is so nice to meet you in person, because I feel like the work that you did has had an impact personally on me. At edooper, we migrated to Swift and of course a lot of the software we use runs on things that you've built. So can we rewind time back all the way to the early 2000s and for some of us who have not really been around there, can you describe like what was the industry like in terms of compilers, languages and what was the status quo back then?

[Chris Lattner]

Yeah, so I mean I was involved in the kind of early days of Linux and so I started, maybe not the really early days, but I started working at Linux in the mid-90s and this is when Java was coming on the scene and a lot of things were changing in the industry as that played out. GCC was the compiler that that standardized a lot of software and a lot of people were using it to build Linux based software. And this is how I got to know it. GCC is a great thing. Before gcc, a lot of people don't know this. Every hardware vendor was making their own compiler and it was a gigantic mess for even just C code because none of these compilers were compatible with each other.

[Podcast Host 2]

And the reason they did that, just so I understand, is like you have C code, it needed to translate to assembly for a specific hardware and then the hardware vendor, you know, they did the mapping and figuring out like what custom instructions or something like that. Was that a reason?

[Chris Lattner]

Yeah. So basically back in particularly like the late 80s and then the early 90s, there's a lot more diversity in terms of like instruction sets and chip makers were innovating and you had HP building things and you had intel was making a lot different systems back then and there's all kinds of different stuff going on. And so you had RISC computers that were being invented. And so the challenge at the time was everybody had to build their own compiler. And so because everybody had to build their own compiler, they all wanted C and some C was emerging and C was a standard. And so there was a spec that said this is what the code is supposed to look like. But as we know from many standards and many specifications, they're never complete. And so what ended up happening is each of those compilers was a gigantic mess because they had different bugs, they had different missed features, they lacked certain capabilities. And so software of the day was built with systems like AutoConf, which was this really weird macro processing thingy that tried to work around some of the limitations and it was a gigantic nightmare. So GCC came on the Scene kind of in the 90s really, and cleaned up, clean up that mess. It became the standardized thing that people could plug into and a lot of chip makers embraced it and it was free software. And so that led to the rise of Linux, Linux adopted it and that really kind of brought the world forward. Now GCC was a good thing, it really did help standardize the world. And I think a lot of free software and open source pays a debt of gratitude towards gcc. But also it was a really old thing and so I made fun of it at the time. It was over 20 years old and its architecture was, you know, very, very old school in many different ways. It was also not built to be a modular design. It had, you know, it was designed to do one thing, take C code in and then put out assembly code for a given chip. And so there's a lot of things that you couldn't do, like JIT compilation and you couldn't at the time even optimize across files within.

[Podcast Host 2]

And JIT is just in time compilation, right?

[Chris Lattner]

Just in time compilation, exactly. And so, and so there's a lot of things that people wanted to do that you couldn't do with GCC. And so in around 2000, that's when I was in university and I was studying compilers and I said, oh, okay, well wouldn't it be interesting to build something new in the space? And so I started working on llvm. LLVM is a, it started out as a code generation system so you could target multiple different architectures. But really for me it was a learning process. It was about saying, okay, compilers are cool, don't let anybody tell you otherwise. Compilers are cool even today, right? Even today. But I didn't really understand anything about it and so I wanted to learn by building. And so across my university project I built this thing up more and more and more. We then open sourced it. It got a little bit of a community. Later I went to Apple which really helped foster and fund a lot of the development. And that early starting point was coming from. You know, GCC and open source technologies are really good, but there's a lot of things we can't do. And so that's where I kind of fell down this rabbit hole.

[Podcast Host 2]

And like when you started an open source, what did you. Open source?

[Podcast Host 1]

What could it do?

[Podcast Host 2]

Yeah, and then, you know, what was the reaction to this early version of llvm?

[Chris Lattner]

So LLVM back in the day, and this is super funny because many people look back on successful systems and they assume that everything was obvious when actually every step along the way is challenging and you have to earn any success you get. Very rarely do you look into it. And so when I first started working at llvm again it was a research project out of a university. There's a lot of research projects at a university that don't go anywhere.

[Podcast Host 2]

I'd argue most of them probably won't go anywhere.

[Chris Lattner]

Exactly. And the default assumption is that LLVM also would not go anywhere. That's a safe assumption for any versity project. And so we used it internally and so my advisor Vikramadhvay encouraged us to continue building it and then we taught it to the, to a couple of classes and so we had a few people using it internally and we got some like use case with it. But at that point it was really just optimization and co generation. And so it plugged into gcc, used the parser and the to actually parse C code for example. And so it was just about code generation and it was useful for compiler people trying to learn things, but it wasn't very useful for general application developers really when we open sourced it then we got, I don't know, two or three people that were interested in it and it was mostly other compiler nerds that are delightful. But there was no major community, there was no major reason for people to contribute. And what I did was I said, okay, well actually just treat the world like the rest of the research group and just have open development. Encourage people, if they combine, they want to help and do something awesome. If they have questions, I'll answer them and just treat people with respect. And what happened over time is slowly the community grew. We got an individual people that were interested in different things. Some people were interested in esoteric programming languages and they were interested in compiler technology for that reason. Other people were interested in performance and different people had different interests. And so very, very, very slowly it kind of grew.

[Podcast Host 2]

And what was the big difference between GCC and llvm? Right, like of course modularity was one thing, but also you mentioned capabilities that you wanted to do that GCC was just either couldn't do or was really difficult to do. What were those capabilities?

[Chris Lattner]

So originally it was just in time compilation. So runtime code generation, that was the thing with gcc.

[Podcast Host 2]

GCC couldn't do, they could do only.

[Chris Lattner]

Compile time, they could only do kind of batch upfront traditional UNIX style code generation at the time, GCC could not optimize across files in your project. And so if you had a C, if you had a function in one C file, it could not inline it into another C file. So things like that. LLVM is also written in C, which was highly controversial at the time because GCC was all C and Richard Stallman was very opposed to C. And so actually there's a parallel Universe because in 2005 had joined Apple, we decided, okay, well, let's see if maybe LLVM and GCC should merge. And I actually proposed to the GCC community, hey, we've got this interesting technology. This seems very complementary. It could lift the architecture of gc. Maybe we should do this. And it didn't go anywhere because primarily it was written in C, but it was also not invented here. There's a bunch of other very serious, very experienced people and they're like, okay, kid, why would we listen to you? And so it did not go anywhere. And thankfully, so it meant that LLVM had to grow up on its own.

[Podcast Host 2]

And then did LLVM really start to take off when you got to move to Apple to now work on it full time? I assume there must have been at least a small team investing in this. Is that how it went or something different?

[Chris Lattner]

Yeah. So the story of getting to Apple. So when I was graduating, I was looking for jobs in compilers and jobs that ideally would let me work on LLVM and continue the work because it was still an advanced research project, it was five years in, the community had grown quite a bit. I was doing regular releases every six months. And so it was really putting a lot of energy into advocating for the work and showing momentum and velocity. It caught the eye of a VP at Apple and there was a couple of people that were working on adding a PowerPC backend to LLVM because that's what Apple was doing. And so I got to know them and they said, hey, come like, we are frustrated with gcc. That is the foundation of all of our compiler technology.

[Podcast Host 2]

Because GCC compiled objective C, for example. Right?

[Chris Lattner]

That's right, exactly. And so, and it was again an older architecture. It was very difficult to work with. They weren't getting the performance they wanted. It was very difficult to add features. The community was also kind of annoyed with Apple for a variety of reasons. And so basically management said, come like work on llvm. And I said, yes, sign me up. And so when I started, they did give me one other engineer to work with, but really they didn't give me a whole lot of guidance. And so I was like, okay, pretty much cool, I will go implement PowerPC support and integrate with the Mac OS back in the day and things like this. And then there became a time when they said, okay, cool, you're working on this. And my manager said, it's great that you're working on this cool technology, but at some point we need to make sure that it's actually relevant to Apple.

[Podcast Host 2]

Was it not relevant?

[Chris Lattner]

Well, it wasn't used in any products yet.

[Podcast Host 2]

Oh, I see, you added support but it wasn't used just yet.

[Chris Lattner]

Just yet, yeah, exactly. And it wasn't as good as GCC in a number of different ways. And so I basically got the vibe that it's like, okay, well after a year if Apple's not using some product, then we'll ask you to start doing something else because we're not just going to pay you to work on an open source project. How it works actually have impact on our company. And so when I got that memo suddenly, and my manager helped me a lot, he was amazing. Went around shopping for okay, well what are the near term impact that we could have on the business? And so from there the first use case was actually for graphics. And so OpenGL was doing just in time compilation to do some graphics stuff. And so we were able to do something very small that actually had value. And suddenly, aha, this is not just a science project. This is actually interesting now. Still missing tons of features, but that enabled the development of the next set of features. The next set of features, the next set of features.

[Podcast Host 2]

And it was now in a product that Apple actually used and shipped and it was, you know, generating business value, if you want to put it like that.

[Chris Lattner]

Oh, small amount, but at least non zero. Exactly. And so, and so what I did over the course of many years across Apple is then say, okay, cool, we'll keep investing the technology, keep building an open technology and an open team, so community, but make sure to deliver more and more and more and more value to Apple. And as that happens, suddenly what ended up happening is I ended up replacing all of the developer tools, compiler, code, generation, debugger technologies within Apple.

[Podcast Host 2]

And that one step at a time.

[Chris Lattner]

Exactly. And so over the it took about five years to the point where we built a new C parser clang and objective C front end and all this kind of stuff. We got to about 2010, that's when Apple was releasing the first 64 bit iPhone and suddenly this was made possible by LLVM, by all the technology we had built and all this kind of stuff. And it was a, it was a epic moment in the industry. Because Everybody's convinced that 64 bit phones were stupid. That was not a thing. And 64 bits doesn't make sense. Why are you going to have more than 4 gigabytes of RAM in a phone? Right? Hilarious.

[Podcast Host 1]

Wow.

[Podcast Host 2]

Back in the day. Yeah.

[Podcast Host 1]

But that's how people thought, right?

[Chris Lattner]

Like that's how they thought. And they're like, it's inefficient, it can never work. And so it actually the first 64bit iPhone, it was the iPhone 5s shipped in production before ARM got their chips back to test. And so we had built the entire software stack, we enabled the entire operating system, the entire tool chain, all this kind of stuff internally. Then we were collaborating with arm, but they had no idea how far ahead we were. And then suddenly we're shipping it in production and the whole world's heads explode because how good the performance was and how all the capabilities we enabled and it was quite fun.

[Podcast Host 2]

So I'm having just trouble putting two things together and you can help me out with what I'm missing. On one end you made it seem like okay initially when you got to Apple for a year it was an experimental project, then you just went slowly with one team and, and after the other. But now next thing we know, fast forward to four or five years later, it's actually powering like the core of Apple. How did it go from like, you know, the small projects to actually getting into like the core of the business? Did it help that you started with developer tools and more developers were convinced, like how did you get through to you know like probably the highest level kind of architects and decision makers who in the end I assume they had to take a risk on technology that was like somewhat new compared to like at least GCC that's been around for like 25 years at this point.

[Chris Lattner]

Well, so it was a combination of having top down support so people that wanted me to be successful and that's because they're frustrated with GCC and so they want a new technology. So that was very helpful. A combination of bottom up success and it wasn't one thing. It was like every six months we'd have a new thing that worked well and go. I became known as somebody who would get things done and so I got more scope and responsibility. And so my, you know, I went from being an engineer to a manager to a second line manager to eventually a senior director over the course of a number of years. And so it wasn't one thing, it was just a lot of hard work and it was a lot of fun because we were able to. You know, a great thing about Apple back back in that time was that you could have a lot of impact because the team was growing. But also if you could get stuff done, you had an amazing platform in which to work because the iPhone came into existence and a whole bunch of other technologies were made possible. And objective C was very Apple specific, but we could move it. That was huge. We had a whole bunch of feature subjective C. And so as we built into this, like there was a lot of opportunity, but it was hard won, right? It wasn't in. In any given moment, it wasn't guaranteed. But as my team at Apple was making progress, we were doing all this in the open. Then suddenly other people started seeing value and like Cray built a supercomputer and used LLVM for it. And Google eventually adopted it 2010 and started using it within Google for some small things. And then kind of a parallel project within Google of another hero within Google, like built a team and added a lot of impact to Google, therefore justifying more people to work on LLVM within Google and different tooling, different projects and different things that all happened eventually. You know, intel or ARM or these companies ended up canceling their internal compilers and switching to llvm. And so then suddenly the vast majority of their engineering team's all working on a thing. And then what you get is you get value that compounds and you get a. Today, LLVM has a community of thousands of people that come together. And so it's amazing to see that.

[Podcast Host 2]

It's incredible. It feels a little bit like when you're starting to roll, snow falls and you're starting to roll this small thing and then, you know, you do it for long enough and most people don't do it. But then you, you could have a snowman and you're like, oh, where did you get all that snow from? Just incredible.

[Chris Lattner]

Well, so, I mean, it's funny because people always imagine success, right? And so you start from a starting point, you say, oh, I want to be the President of the United States or something. And some people get very motivated by that and it's very powerful. What I really love is doing all the work, taking each of the steps, doing the thankless thing, figuring out that really obscure thing that if you get the architecture right, it makes the whole thing compound and scale and compose the right way. And it allows you to solve problems that nobody else can solve. But what that means is most of the time I'm working on things people don't understand. And so I'm fine with that. I've normalized to this. This is what I expect. At this point, I don't expect people to understand me. But what happens is that these projects, over time they grow and they get to the point where suddenly it clicks and suddenly people start to understand. And suddenly you can explain it because it maps into their value system in a way that, you know, they can measure.

[Podcast Host 1]

Basically, Chris just mentioned how things click a lot more for people if it maps to their value system in a way that they can measure it. In my experience, measuring things is helpful all round, not not just when trying to convince people, but also when figuring out if a feature you built works as you expect. Here's a challenge most teams face. They shift features but cannot easily measure if they're working. Did that new checkout flow improve conversion? Is the feature helping retention or hurting it? Without measurement, you're just hoping things will work. That's where Statsic comes in. Statsic is our presenting partner for the season and they've challenged the status quo of how product teams work, much like how Chris challenged how compilers and programming languages are supposed to work. Most teams accept fragmented tools, feature flags in one system, analytics in another. Experiment somewhere else you're stitching together point solutions, running ETL jobs to sync user segments, hoping timestamps align across different systems. That's a status quo, but it doesn't have to be. Statstic built a unified platform that gives you everything in one place feature flags, experimentation, analytics, and session replay, all using the same user assignments and event tracking. So you ship feature to 10% of users and the other 90% automatically become your control group. You can immediately see if conversion changed, drill down to where users drop off in your funnel, then watch session recordings to understand what went wrong. All with the same data. This is how you measure impact at the pace you ship. Companies like Graphite, Notion and Brex rely on this approach to make data driven decisions without waiting for data teams or manually correlating information across tools. Statsic has a generous free tier to get started, and pro pricing for teams starts at $150 per month. To learn more and get a 30 day enterprise trial, go to statsic.compragmatic with this. Let's get back to the conversation with Chris.

[Podcast Host 2]

One thing I feel that is probably pretty applicable for anyone is the fact that you were inside a company that was pretty big and successful at that time, Apple, and you still managed to get so much things done, just as you said, by solving hard technical problems Continuously figuring out how to help the business. And there was this interesting part where Clang got open sourced. And Apple back then LLVM was open source. So that kind of. I understand how that grandfathered in.

[Chris Lattner]

Yeah.

[Podcast Host 2]

But I wanted to ask you on how you managed to convince a company that back then was pretty close, and even today is pretty close outside of a few things to be okay, open, sourcing a new project. And I assume your reputation or hard work or getting things done might have been there, but what else did you kind of use for leadership to like, greenlight this? Because I'm sure top down they needed to say like, yes, right?

[Chris Lattner]

Yeah, well, so Clang was actually the easy one because really, we didn't really ask too many people for permission, we just kind of did it. And so that was the easy one. The hard one was Swift.

[Podcast Host 2]

Let's get this.

[Chris Lattner]

So I think we'll get there, but that was the actual hard one.

[Podcast Host 2]

And with them, let's get to Swift. The story of Swift, as you shared many times, is how you started to work on it in secret. Can you tell me what led you to start experimenting with a new language? What you saw the problems being with Objective C, especially because now we solved the compiler problem. Like the compilation was probably as good as it could have gone. And how did you pull off this kind of, what does secret mean?

[Chris Lattner]

Right. Yeah. Well, so the backstory on Swift is that. So I joined Apple in 2005 and I built and basically replumbed their entire C and C and Objective C tool chain. And by 2010 at WWDC, which is their summer conference, we had launched a full stack replacement and it was working. And building a full stack fully integrated C compiler is no small feat. C even then was a very complicated language and it was a very big technical challenge, but it was also very demotivating because C, at least to me, because C is just a beast of a language. And so he couldn't come out of that and not wonder, could we do something better? Right? And as you said, we'd build a lot of this fundamental technology, could build pretty much anything we wanted at that point. And so I just started again, nights and weekends, didn't ask permission, just started fiddling around, seeing what could be done that would be better. And to me, what I did was I actually said, okay, let's go look at a lot of existing languages, so let's go look at both the new ones. Let's look at Java or let's look at C things, but let's also look at functional languages like OCaml and Haskell and things like this. Let's also look at esoteric languages, like the really weird other things. Let's look at TypeScript and Dart and other things that were kind of on the scene and happening and go and languages like that. And so it was really about saying like, well, what do I like and how do I see success? And what I defined success as with Swift was making it easy to use and scalable. And so I saw a lot of languages. JavaScript is probably the best example of this where, you know, you start with something really simple and you know, we can hack with JavaScript and then, and then it gets adoption and then you get developers and then developers bring their tools to other domains. And so, you know, JavaScript was designed for on click handlers, but now people are running web servers in it.

[Podcast Host 2]

Yep, well, we see that all too much.

[Chris Lattner]

Exactly. And so what my observation was is that success meant that you would be naturally brought into other domains. And so think beyond just the first win, but think towards more generality and scale. And what I realized is if you take something like Objective C, which I was deeply familiar with, for example, this dichotomy between objects and C. So Objective C had this Smalltalk inspired object model and then it had C for performance. It was actually a really beautiful combination because you can get all the way down to the metal with C, but you had high level APIs. And what I realized is that they didn't have to be two languages.

[Podcast Host 2]

So you could take the good parts.

[Chris Lattner]

And pull it together into one system that could actually scale and it would be way easier to teach, way more memory safe, way more modern, good type inference, fix some of the syntax problems. Because Objective C was a little bit of a mashup between two different worlds. And the funny thing about that is that you fast forward all the way to today. That's exactly what Python is. Python is a beautiful language for objects built on top of C and C and Rust and it's got this two world problem going on within it. And so it's very interesting to me just again, how history rhymes with itself. And there's so many different things going on. But the initial ideas of Swift was really about saying, how do we build a scalable language and how do we pull together the best ideas shamelessly, you know, borrowing ideas from different places.

[Podcast Host 2]

And by scalable as you meant that means that it can be used for like your specific task, that may that be, let's say for iOS, but then it naturally lends itself to like other domains.

[Chris Lattner]

Yeah. And so specifically scaling all the way down to embedded systems development, all the way up to something that kind of approach, scripting. Right. So super easy use for very high level programming.

[Podcast Host 2]

Can you tell me, how did you design a language in the sense of like, as developers we use a lot of languages, right? Like again, like I all of us have tried and built with many different ones. Especially with AI tools, it's so easy to try out for myself, Typescript, Rust go the Haskell try out this and that prologue. And I'm used to using them, right? And I kind of discover it, figure out what is there. But when you have a black canvas or when you were thinking how do you go about it? Do you kind of, I don't know, metaprogram, like, kind of write down what you love to see? You also of course, build compilers, you start to immediately think of how that would work. Can you give us a little bit of a, a view of like, how do you go from this blank canvas to like. Okay, here's what I think the language will be.

[Chris Lattner]

Well, so that's a good question for me in general because I start from a lot of blank canvases across my career. Right. So LLVM blank canvas.

[Podcast Host 2]

Yep. Right.

[Chris Lattner]

Mlir later blank canvas. Mojo Swift. Like many of the systems I build are blank canvas projects. And so for me it's a couple of things. First of all, doing that kind of analysis, the reflection, the deciding what does success ultimately look like. Then do the survey, go look at what's out there, what's good, what's bad. One of the things I really strongly believe is that you can take a system that you don't like, but buried within a system, even if you don't like it, that are often good ideas. And so you can take the ideas that are good and ignore all the rest. So for example, Java, I didn't like, like garbage collection and finalizers and like there's all this stuff that came with Java, but being able to be JIT compiled was very powerful. And so there's a lot of things you can look at and you can say, and Java is a huge step forward from the technology space for a variety of reasons, but you can look at that and you can say, okay, well I like that one aspect of it. All the rest of these things are separable. And maybe I don't like how they work and do that survey. And then when I start building a new system, I expect to design and redesign and iterate and learn and grow and what I try to do is I try to go through proof points and validate specific assumptions and say, okay, I'm not going to solve all the world's problems. I'll keep this part and this part and this part super simple. It's like the two circles that make your owl just leave them in circles and then invest in proving this piece. And if I can get this piece done and I can understand that it works and I can gain validation and confidence in that, I can know the interfaces going in and coming out of it. Well, now I can go out into the next system and build that out and build this thing out so that we can understand it and learn as we go. But every step along the way, being unafraid to go massively change and flip over the table and try again.

[Podcast Host 2]

And so you start to experiment with Swift, like the kind of weekends and on the side in 2010, ish. How did it take until 2014 for a first release? Like, what really goes into building out a language? Because again, I think we can all. I can kind of emphasize like, this is cool. Like you have these ideas, of course, you have a lot of experience, you try out things. But then as a software engineer, I shouldn't ask this, but I'm gonna ask this. What took so long?

[Chris Lattner]

Well, so it turns out building programming languages is not easy. It takes about four years, I guess.

[Podcast Host 2]

Can you give us a bit of emphasis of what makes it so hard?

[Chris Lattner]

Yeah. Well, so let me just frame up how it went, just so you know, because the first year and a half it was literally just me working on it. Oh, okay. So nights and weekends. And I had a day job and I was managing a big team and a lot of stuff going on.

[Podcast Host 2]

Hold on. So at this point, yeah, you were.

[Chris Lattner]

Already like pretty second level manage or something and had a team of 40 people running? Yeah, a lot of. A lot of very interesting and very fun stuff.

[Podcast Host 2]

You're good at juggling stuff.

[Chris Lattner]

This is passion project.

[Podcast Host 2]

Yeah, yeah.

[Chris Lattner]

I'm also a fairly good programmer, so that helps. But after a year and a half, got to the point where I told management about it. I said, hey, I'm working on this thing. What do you think? They're like, yeah, no, why would we want a new language? Objective C is what made the iPhone successful. Right, Right. And so like, no.

[Podcast Host 2]

What?

[Chris Lattner]

I'm like, well, how about I just have like one or two of the people in my team, like work on this part time. They're like, I guess you can tell them about it, but we can't commit resources really. But again, I was respected and doing good things. And so I was given a little bit more rope than some other people would and got to the point of saying, okay, let's build up some demos. And then it was about three years in and most of the feedback I was given was, okay, well if you don't like Objective C, go make Objective C better. You know, Objective C also, it's a natural reaction.

[Podcast Host 2]

I mean, as much as, as engineering, I don't want to hear it. If I put a little bit of business hat on, it's what you would.

[Chris Lattner]

Makes total sense. That's what the entire community is using. It's very low risk. It makes your existing investment even bigger. And so what I did was I said, okay, well across that four year journey was not just building the thing full out with like a team of people that knew what they're doing. That's the discovery, the research and also the socialization process with executive leadership. And so what I realized is I said, okay, well I want to have memory safety. Objective C does not have memory safety. That was one of the biggest things retain and release. And it was completely manual and it was just a kind of a nightmare. And so we invented arc, so a way of doing reference counting automatically that made objectsi way more teachable and safer. It also pulled it much closer to Swift. We then did modules, we then did literals and Objective C. We added all these features that what it was doing was pulling the lived experience of doing Objective C programming closer to what Swift would be. So that ultimately when Swift came out, it would be less of an abrupt leap. And it was still a pretty big leap, but we were doing that. Um, but meanwhile, you know, management's like, okay, cool, why are you doing this? And they're having their own issues. And we got to about three years in and said, okay, well we think we should do this in a serious way. At that point I had a team of 250 people, ish, something like that. I was running Xcode and the whole developer tools team and, and still on.

[Podcast Host 2]

The weekends you were still doing this.

[Chris Lattner]

Well, yeah, you can look at my GitHub history. Like you can go back to 2014 and see what I was doing. Yes. But at that time, right, they, they said there was this big executive review and a whole bunch of internal discussion. And I said basically, look, I want this to be the focus of the department to bring us into market. And so at that point we didn't really have it talking to iOS, right. It was still missing a lot of the object features and things like this, we had no apps that were built with it. And so that last year was a massive amount of work in terms of finishing language, but also integrating with the debugger into xcode, into code formatting and to tons of different features. Building more integration with the iOS SDK, that was a big deal and we had not done that. And so a lot of that made it possible to finally launch it four years later. And I would say when we launched it. So a mistake we made is we called it 1.0.

[Podcast Host 2]

I was about to come to this because that's where I have firsthand experience with 1.2. But yes, 1.0 came out and the feedback, I can just talk from what I remember from there, there's two things. People were super excited that Apple is releasing a new language. And iPhone was huge. 2014 was the time where you knew that you could build a big business on iPhone. Uber, I think, Snap, all of these companies were just going up. It was a status symbol already. And not everyone had iPhone just yet. However, when you tried it out, it was just not good. Xcode didn't have refactoring support. Debugging was a nightmare. We should have launched it the bird of the five. So that's. So how did it go for. Why did you decide at the time? Like, you know, just. I'm interested in your thought process at the time on how we went about it and, you know, like, what were some learnings now that you look back?

[Chris Lattner]

Yeah, so. So it had to be 1.0 to launch it, because Apple doesn't launch 0.5, basically. So it. If we wanted to launch, it had to be called 1.0. So that was one aspect of it. But the other aspect is we wanted to get it out there. And at the point that we launched it, only about 250 people at Apple knew about it at all. Most of those people are in my team and then some executives in marketing and other people like this. And so we knew we couldn't build a good programming language in a vacuum with an NDA that you had to sign to get access to it. Right. You have to actually get it out there. You have to get usage experience. And so the learning for me is don't call somethings or 1.0 until it's actually ready and it's validated and you have a lot of usage experience and things like this. We bring a lot of these lessons to Mojo.

[Podcast Host 1]

By the way, Chris Laffner and the team launched swift back in 2014 and it's since become the de facto way of building native iOS apps. Which brings us slightly to our seasoned sponsor, Linear. Linear's iOS app is also built on Swift. It's a fully native app. It's not built with React native or using a web wrapper. And there's good reason for this. Linear's entire philosophy is about speed and performance. The desktop app is famously fast, but that same obsession about speed carries through to mobile. Linear have just redesigned their mobile app with something pretty interesting their own take on Apple's Liquid Glass design language. But instead of just using Apple's API under the hood, they rebuilt the UI from scratch. The Linear team wanted more control over the navigation and customization than Apple's system would allow. Classic engineering mindset if the existing solution doesn't give you what you need, build your own. Here's my favorite detail about the app, though. Linear has this feature called Pulse. It's basically a feed that gives you an update on all your development, project updates, what's on Track, what's blocked, etc. On mobile, you can actually listen to it as an audio briefing. The Linear team told me how they get raving feedback from engineering leaders to listen to their puls update on their commute. It's like a personalized podcast about the team's work. One VP shared how he gets to his entire standup prep while driving to the office using puls. This is why I love partnering with engineering teams like Linear's. They're not just porting desktop features to mobile, they're actually thinking about how people use their phones differently. If you want to see what they're building, check out Linear App Pragmatic. You can use the mobile app to manage issue tracking on the go. And that Liquid Glass implementation is genuinely beautiful and during work. And now let's get back to Swift 1.0 and how the language is pretty painful to work with on launch back.

[Chris Lattner]

In 2014, but also it's about making sure that we communicate clearly with the community. And so one of the things I think we did well is we said look internally at Apple. We said, look, we need to launch this. We know it won't be perfect. And so we're going to tell the community that you can adopt it and you can build apps and submit them to the store, but we will break your source code. And this is because we know that we have to change the language when we get usage experience. And so we told people like, we will help you, but expect code breakage. And I'm glad we did that.

[Podcast Host 2]

I remember that was really clear. People were upset about it, but they knew like when we had the discussion of should we move over to Swift or not. And at Uber, the Rewrite happened in 2016 where Swift was at 1.2 and the platform team made the decision after evaluation that they will take a risk. And it was a big risk and there's now stories about it. I have a blog post. There's some other people with their experiences, but they did it because they knew that Apple is committed. I think the open source part also helped build a lot of trust and I almost feel that that was one of the last times that I saw like the Apple community really unite against like iOS developers specifically. Just go like, you know what, we'll be in the pain together. We know it's going to be painful. But like all mobile engineers I know knew that this was pain. They told their, you know, their management and all that. They said this is the right thing to do. And of course think it really helped that Apple have like this trajectory. And it was like, okay, well they didn't want to be left behind. They wanted to risk not having access maybe in the future one day to APIs. Not at that point. One thing I was surprised when Swift was launched. I don't know if this was right on launch day, but Xcode Playgrounds and the repl, the read about print loop, that was launch day. Yep, was also part of launch day. And you know, for those that don't know Xcode Playgrounds, it was like you could just like try inside Xcode you could just try Swift. And with Repl, you could also just really easily play. Why did you decide that that needed to be there on launch?

[Chris Lattner]

Well, so part of that came from that year long process of like getting it to launch. And so part of it was, okay, if we're going to do a new language, what are we going to get out of it? What is the developer experience? Everybody wanted to get something right. And so for example, the documentation team who I love said this is our chance to write a book. Which was awesome because Swift had a book on launch and it was fantastic. The Xcode team said, okay, well. And management and marketing people said, okay, well can we get interactive programming? This is something we've never had and so we want that. And so that's where Playgrounds came from. And so the REPL came from me saying, okay, well modern languages should have a repl. This is a thing that builds into the debugger and there's a bunch of different capabilities we could use and it would make a lot of sense to make it much more modern feeling. And if we're going to do this, let's do it right. And so there's a lot of that, okay, if you're going to do it, let's get the advantages from it. Now, the flip side of it is we were massively overextended and so a lot of the vision was right. But particularly at 1.0 and even 1.2, many of these things are still unbaked and it took a long time. And I think that we underestimated how hard some of these things were. And waiting for 2.0 or 3.0, you know, maybe would have been better for some of this. But anyways, it's easy to be negative and judgmental in hindsight. Right at the time, we were all working really hard and trying to make something amazing, and we're learning as we went. And I was really thankful for the community. But one of the other things I'll say is that while you may have been on the oh, wow, awesome thing and let's adopt and let's get ahead of the curve, there are just as many people that were the what are you talking about? Objective C is great. If you ain't broke, don't fix it. And they're like shaking their fists and saying like, I will never use a new thing and blah, blah, blah, blah, blah. And there's all these bad things which they write about with Swift. And so it took quite a long time for the community center of gravity to move.

[Podcast Host 2]

Well, this was a fun fact. In 2016, I remember middle of 2016 or maybe a little bit earlier, Uber was one of the big mobile first companies built on iOS, grew up on iOS, lived and breathed iOS and of course Android and the mobile platform team ran a survey in sometime early 2016, two years after Swift was out. This was Swift 1.2 saying, we are planning to rewrite the app. The rewrite was a thing just because.

[Chris Lattner]

They needed to for architecture.

[Podcast Host 2]

We needed to redo every single screen, every single interaction, which kind of meant a rewrite, all the business knowledge. So it was going to be a rewrite no matter what. And they ran a survey. Would you Prefer, as an iOS Engineer, Objective C or Swift? And the results were pretty much 50 50. And these were again very experienced engineers. They knew. And the two camps were violently disagreeing with another. And I still don't know why Uber went with Swift. Someone was a tiebreaker in the end. But back then, this is how foot on foot it was. And of course there was grumbling, there was problems. So the Objective C people said, like, told you so. We could have just. There was at some point thinking of, like, maybe we should go. But as you say, it was not trivial. But I guess this is what you don't see in hindsight.

[Chris Lattner]

Well, but I've learned a lot. And again, you reflect forward because this impacts exactly what I'm working on now. Same thing, which is that with mojo, experts don't like change. Right. What I got.

[Podcast Host 2]

This is counterintuitive.

[Chris Lattner]

Well, I mean, if you think about it, if you're an expert Objective C programmer, I don't know if you were, but if you're expert objective programmer, you've been doing it for five or 10 years, you've learned all the bag of tricks, all the weird cases, you know, all the arcane thing. You are the person that people turn to for help. Swift comes out now your expertise is invalidated. You're on day one, just like everybody else. You are not the expert. You don't really want a new thing. You want to be the king of the hill of the old thing, and you don't want the new thing to be successful. And so now some people are intellectually flexible and will switch over. And there are early adopters and things like this or people that like new things. And so it's not true of everybody, but it is actually sensible human behavior to protect your prior investment. And for a lot of people, you have to have a really good reason to switch over. And so in the case of Swift, SwiftUI was a reason that moved some of the Long Tail people, which was years later, years later, right? So there's different inflection points. And so what you look at is it's almost technology diffusion, right? And so they're early adopters and they'll get on board quickly just because it's a shiny new thing. And then there are some people you have to drag objectives together called dead hands, right? And so like everybody else gets mapped somewhere along this curve and it kind of looks like an S curve.

[Podcast Host 2]

But this is interesting because this will, you know, we're, we're, we're going to get to like some of the, like AI and LLMs. But I feel this playing out.

[Chris Lattner]

That's right, that's exactly the same thing. And it's, it's part of human behavior. It's not about Objective C. Now, now let me tell you the thing that I find most, that I'm most proud of in this journey. So when I started 2010 and it was just a toy project, like playing around with it in spare time, not expecting to go anywhere. I was kind of implicitly coming from the assumption that we could do something that was better than C and Objective C and that was more easy to use and things like this, but didn't really know how it would go. After we launched, I would have people that stopped me in the streets and said, thank you, Chris. Because of Swift and because of not just me, but the whole team working on this, I was able to become an app developer. Before Swift, I tried building apps with Objective C, but I could never figure out the pointers and the square brackets and it would crash and I couldn't. Like I'm not smart enough to build an app. But now with Swift, it became easy enough that even I could do it, and now I am an app developer instead of a web developer, and I've become the expert in my company and now I have learned and grown in my career. And so now, thanks to this new technology, like, I progressed, and if not for this enabling technology, it never would have happened. And that's the exact same thing happening with GPUs right now. We have the exact same thing with Cuda and C and all these tools that are gatekeeping so many developers away from this emerging kind of compute and kind of technology. And it's the same exact thing. And so this is what really makes me passionate about working on this kind of technology. Because I believe in the power of programmers, I believe in the human potential of people that want to create things. And that's fundamentally why I love software, is that you can create anything that you can imagine. And to me, that's what's so powerful about working in this space.

[Podcast Host 2]

I really feel it and see it. Just looking back on Swift, because you created it, it's your baby. It started as a project. You were a guardian of it, or shepherd, or however you want to call it for a while. And of course now you've stepped away. It has its own life. Looking back at it, how do you feel on how the language has evolved? What are parts that you're really kind of happy? On how it lived up? What are parts where you're thinking that maybe if you would have stayed longer, maybe you would have, like, tried to have it in different ways, if there's any.

[Chris Lattner]

So it's very hard for me to say if I'd stayed at Apple and if I had kept my, my fists on it and like controlled it, if it would have been better or worse. But I, I can talk to the mistakes that I made. Right. Because. And their learnings that I could bring forward. And that way it's my fault and it's not me saying other people weren't able to do it.

[Podcast Host 2]

Right, Fair, I like that.

[Chris Lattner]

But like early Swift, it was, you know, I'll just say it bluntly. I didn't know what I was doing.

[Podcast Host 2]

Right.

[Chris Lattner]

So I'd never done it before. I'd built a C compiler which had a spec.

[Podcast Host 2]

And what was the first language you ever built?

[Chris Lattner]

It was the first language I'd ever built. Right. And so a lot of the ideas going into it were new. A lot of the, like the type checking algorithms were exciting, but I didn't really know what I was doing. I'm also not a math guy, and so if I actually understood math, then maybe it would have been obvious. But things in Swift like expression 2 complex to type check in reasonable amount of time, that's my fault. Right? And there, there's specific features that cause that to happen and it's very difficult to fix. And, and so that's one mistake. Another mistake is that we were very ambitious in terms of adding features that we wanted to see in the language, and we added them faster than the architecture could keep up. And so, particularly if you talk about swiftone, but even today, what ended up happening is the internals of the compiler and the design didn't really line up right the right way. And so you get a lot of things that work kind of 80% or 90% and they didn't quite fit together. And then as you start adding more and more and more stuff, it doesn't really line up right and it just gets more and more complicated. C has the same thing going, by the way, and Swift's not unique this way, but as a consequence of that, like, you get an emergent complexity that then developers can feel In Swift today, people make fun of too many keywords and things like this. Well, it's because the origin story was really not, in my opinion, didn't put enough energy into like, really refactoring, really redesigning, really making sure the core was great. Instead it was, okay, let's get to app development as quickly as possible. And so as a consequence of that, what happened is then, you know, I and many other good people put more stuff onto it and more stuff onto, and more stuff onto it, and the language got more complicated. And so, you know, partially, that's maybe in any individual decision, but also it's because some of those original things didn't line up the right way. And so the complexity kind of compounded.

[Podcast Host 2]

Wow. I'm just like hearing we have a lot of tech depth inside a language and it builds up.

[Chris Lattner]

Yeah. Well, I mean, if you look.

[Podcast Host 2]

Well, I mean, this is just one way of putting it. Of course you put it differently, but it just feels it all repeats itself, like it's whatever project you do.

[Chris Lattner]

Absolutely. Well, let me talk about, like a simple example. In C. In C, int is hard coded into the language.

[Podcast Host 2]

Yep.

[Chris Lattner]

Float is hard coded into the language. Complex numbers are not. They're templates.

[Podcast Host 2]

Why is that?

[Chris Lattner]

Why don't you just get rid of these concepts, have one fewer thing and just make int and float part of the library and then everything's more self similar and everything will work the same way, et cetera. And so Swift fixed that problem.

[Podcast Host 2]

Right.

[Chris Lattner]

So int and float are now part of the library. And all this stuff is much simpler in that way. Right. But C, you can't go back and fix it because it comes from C. And so they added templates after C. And so all the C stuff had to be hard coded in. They couldn't fix that. And that's the origin story of why C works the way it does.

[Podcast Host 2]

When I was talking with Steve McConnell on the podcast, he told me that he, when he worked at Microsoft for a while, the best developer he met there did this thing where he wrote everything three times. First he wrote a first version in like a week and a half, then a second version in three days and a third version in a day. And when I think back of the history of Python that I just heard, there's documentary where we can listen to it. It was also the second or third iteration of language. And what I'm also hearing now is also in Swift, you saw some mistakes in C, but you couldn't forecast some of the things. But now we're going to get to Mojo as well.

[Chris Lattner]

And that's always my goal. Right. The goal is so you're always going to make mistakes in life. So there's things you can do. You can decide to make new mistakes. So learn from the past and make new mistakes, not old mistakes. And then you can make the decision to fix mistakes wherever possible. And then you try not to paint yourself into a corner. And so again, a thing that I think Swift did well is it said, okay, well, the initial release was 1.0. That was predestined, but we're going to break the language. And so Swift one, Swift two, ultimately to Swift three broke the language to try and make it better. And then only at Swift 3 did we say okay, now it's stable. Right. And I think that was really good because can you imagine if it's still Swift one?

[Podcast Host 2]

But we would be left with all these mistakes, all the mistakes.

[Chris Lattner]

Right. And so it was painful, but I think that was a good set of decisions we made and it led to a much better result.

[Podcast Host 2]

Yeah, there's a lot of trade offs. So as we get to what you're doing today, after Apple you worked at a few interesting places. Tesla, Google, Brain, Sci Fi. Can you talk about what you've learned at each of these places and kind of how it's. Because I think it'll be interesting to look back on how it just all is leading to what you're doing now.

[Chris Lattner]

Yeah, totally. So the way I frame it up is that 1.0 of my career was at Apple and building developer tools and understanding CPUs and I built OpenCL which is a GPU thing also and compilers for the GPU and like all this kind of stuff. And so learning a lot about that hardware software boundary and developers and developer tools and Xcode and like that whole thing. Right. 2016 I fell in love with AI. And the reason was is that about 2016 the Photos app had the ability to tell you is this a cat or is this a dog? And it was a very like it was inception v1 or some really ancient AI model was in there. I'm like, I own developer tools, I know a lot about programming, I have no idea how to write an algorithm to detect a cat in a picture. How the heck does that work? So I fell down this rabbit hole in 2016 and this is what leads me to 2.0 of my journey which is a very AI focused like go figure all this stuff out. And so Tesla is doing applied with self driving cars. That's where I Learned Cafe and TensorFlow and I realized TensorFlow was a good thing, but it could be a way better thing. And so that led me to joining Google and helping scale TPUs there I ended up owning the bottom part of TensorFlow, all the CPU, GPU, TPU, plus a bunch of other weird internal ASICs within TensorFlow. But notably I scaled the software platform for TPUs and across years learned both. Hey, it's actually really hard to make AI software without CUDA. TPUs don't have CUDA.

[Podcast Host 2]

CUDA, which is Nvidia's way to program kernels, right?

[Chris Lattner]

Yep. So basically the entire AI ecosystem back then, but also today ends up being very heavily biased by Nvidia. And by their API and software and language toolkit called Cuda, which is also.

[Podcast Host 2]

Like 20 years old or so.

[Chris Lattner]

It's about 20 years old and it's awesome and it's very mature and there's a lot of good things about it, but it's also 20 years old. And so there's time and space for new things. But when you're building an ASIC, so TPUs are very large scale data center training and inference accelerator. Very fancy, very, very frontier. Particularly back in 2017, you don't have software and so you have to create everything from scratch and then you have to get TensorFlow and PyTorch to talk to it. And nobody really understood how that worked. And so across the years I learned so much and I'm so thankful for my experience at Google because I learned about the algorithms, I learned about AI, the frontier applications, like, you know, the attentions, all you need. Paper was invented in that time frame on TPUs. And so we. It was, wow. Yes. And so tremendous amount of things going on, large scale embedding systems for ads and recommenders and stuff like this was going on. It was, it was a broke, brilliant time. And so across that, kind of an early version of what I'm doing now said, okay, well we need to reinvest in the software technology and the platform for technologies. And so I built components of what is now, I think, pretty widespread AI software. So there's this MLIR framework, new runtime technologies, a whole bunch of different things. So each of these things ended up being kind of 2.0 of the first leg of my journey. And so MLIR is a compiler framework, it's kind of like LLVM 2.0. And so it's a rough analogy and we probably won't go into MLIR full details, but.

[Podcast Host 2]

But it's for ML, right?

[Chris Lattner]

Well, it's for, it's for domain specific chips and. Domain specific chips. Yep, yep. And. And so. But I could not have built that without the experience of building llvm.

[Podcast Host 1]

Right.

[Chris Lattner]

And so having gone through that experience and being willing to do a 2.0, a clean slate, you know, looking into the abyss, you know, you're standing on a cliff and every. It's just blackness around you and you could do anything, but you have to decide where to start. Right. That really helped. Having gone through that and having made a bunch of mistakes with LLVM and being able to then fix them. And so we were able to build something that has now been widely adopted by roughly every AI company or every AI chip company that exists, which is very exciting.

[Podcast Host 2]

Wow.

[Chris Lattner]

And through that journey at Sci Fi, for example, then said, and scifi built specific like built CPUs right.

[Podcast Host 2]

On RISC, one of the best in the world, as I understand.

[Chris Lattner]

So scifi builds RISC V hardware, RIS5 hardware. Yeah. And so I decided, okay, I've always been on just the software side of the hardware, software boundary. How about we go play on the other side? That sounds fun. And so I learned a tremendous amount about physical design and chip design and the business model of hardware and IPs and like all, all the different technology for verification and things like this and, and tremendous amount of fun. And one of the things we decided to do is let's go build an AI chip or an AI ip. And so you get to that and then suddenly you get to where's the software? And so across like each of these legs of my journey, I'm like, okay, where is the software? Where's the software? Where's the software? And in the case of AI, there's basically nothing there, there's nothing that you could take off the shelf that provides an end to end AI solution that you can then just go implement your chip. And so, I mean, the origin story of modular really came down to my co founder and I, who were buddies, we got to know each other previously at Google, but really saying like, you know, we need something like lvm but for AI, but for AI, like we need the thing that people can implement support for their chip into it and then get an AI software stack. Because, you know, if you're building CPUs 20 years ago you didn't want to have to build a whole C compiler and C compiler and code generator and kernel and web browser. You just want to do a little bit of work and then get software. And that doesn't exist for AI right now.

[Podcast Host 2]

And then for those of us who are software engineers, but we don't build AI software. We just, you know, we use the models. We might invoke the API or we might invoke the trained one. Can you explain to us if we moved into the world of actually building AI applications, running them directly on GPUs, may that be Nvidia or now there's AMD or Google TPUs. What software would we use today? What is the status quo? Or what was at least the status quo when you started modular? And then what is your vision? Which I sense there's a bunch of similarities with GCC and LLVM here.

[Chris Lattner]

Yep, absolutely. So before gcc Every chip maker had to build their own software stack. That's literally the shape of AI software today. Because there is no thing to plug into besides modular. Everybody has to build their own vertical software stack. And so when I was at Google, we built a thing called xla. That's the thingy that we built, kind of like Cuda, but for Google TPUs. For Google TPUs, you look at Apple, they have, you know, metal and MLX and their, their whole stack. If you go look at amd, they have rocm, their whole stack. Everybody has to have their own verticalized stack and they share very low code.

[Podcast Host 2]

Oh, so this is why I was just looking at. I talked with some folks at Anthropic and look at their job sites and I saw that they're hiring both CUDA engineers, but also Google TPU kernel engineers.

[Chris Lattner]

And Trainium, which is the AWS and Trainium. And so they're writing the same models three times over and over again, depending.

[Podcast Host 2]

On the hardware they do. And then I guess when it's a new version. Okay, I get it. So this is where we are today, or where we were at least. Well, that.

[Chris Lattner]

And so like you mentioned Anthropic, they have an amazing engineering blog post from a few weeks ago. I can remind me and I can dig up the link.

[Podcast Host 2]

Yeah, we'll put it in the show notes.

[Chris Lattner]

It talks about the problem of reimplaying same models three times over. Turns out they don't work right. You have bugs, you have quality problems that then users can feel in your product. You have outages. Because implementing things three times in parallel with three different teams, of course they don't line up. So where modular came from was saying, okay, well I've lived this experience with Google with TPUs and a number of other chips by the way, but TPU's with a public one have seen this at Sci Fi building into the hardware ecosystem at that point. This was about four years ago. At this point, the AI hardware ecosystem wasn't mature. But suddenly I had built up this wealth of knowledge of like how to do this stuff. And when I looked around at all these projects, I looked at Pytorch, I looked at there's Onyx runtime and like there's a million of these things out there. And it's like anybody's on the right path. Nobody was willing to do the work. Because what I saw is I saw the problems I faced at Google. I love my experience at Google. I learned a tremendous amount. The people are amazingly brilliant. But the problem that I had and that we had as a team was that every year there'd be a new chip and every year you're scrambling to get the next chip to work. At the same time, all the product teams are using the current chip and so all your best people are getting assigned to put out the burning fire for search or ads or whatever the work, YouTube, whatever the workload is. And so you could never actually get the mindset or the bandwidth to be able to do something fundamentally new, particularly if it took more than a 6 or 12 month performance review cycle.

[Podcast Host 2]

Oh yeah, Google was infamous for that.

[Chris Lattner]

And yeah, and so what I saw is I saw a lot of these very short term projects and a lot of improvements and a lot of micro optimizations and a lot of great work, a lot of massive innovation in models and the architectures. But the progress, the research progress was happening because Google had infinitely smart engineers that had built every level of the stack and could hack the daylights out of it just to make simple things work. It wasn't scalable, it wasn't beautiful, it wasn't like built to compose, and it certainly wasn't built to bring up new hardware quickly. And so, as you know, I've been working in compilers and dev tools and languages and stuff for quite a long time. And so I said, okay, well I think it's finally time to solve this problem. But to solve it, you can't solve it in a weekend with, with like three people. You need years of time and a deep, very high tech team to be able to invest in this technology. Because Cuda, as you mentioned, is 20 years old, it's had thousands of people work on it, huge investment. Any one of these chips and these algorithms is extremely complicated. The AI research landscape moves really fast. You need a huge amount of effort. And the only way to tackle this was with a VC funded startup, because that's the only way we could pull people out of Apple and Nvidia and Meta and Google and all these companies to be able to go build this.

[Podcast Host 2]

And you said something interesting in a previous podcast or interview. You said between kernel engineers, compiler engineers and AI engineers, they just kind of think differently and there's not much overlap. Can you tell me a little bit about. Because you have been all three, you of course know so many of them, but what is the difference? In the end they all need to work together at a place like this. But you said that somehow they don't understand each other.

[Chris Lattner]

Yeah. So I'll tell you the, the aha moment that came to our technology approach for modular. Again, if you go back four years ago, you're talking 2021. Funny how that works. Okay, so late, late pandemic, a lot of amazing stuff had been done and a lot of people have built. First of all, TensorFlow and PyTorch, I consider them to be some of the very early production frameworks. TensorFlow, PyTorch, both come from 2015 by the way, so they're nearly 10 years old, which is ancient in AI time.

[Podcast Host 2]

Right.

[Chris Lattner]

And so they were built under this idea of we will take Cuda kernels and we'll take Intel MKL kernels and then we'll build Python APIs on top of these. And so one of the challenges with that generation system is that it was so easy to write kernels that people made thousands and thousands of kernels, but then they couldn't be ported and you had to rewrite thousands and thousands of kernels to be able to bring up a new chip. But when we worked on TPUs, we said, Aha, you know, it's cool compilers. And so instead of writing thousands and thousands of kernels, what we can do is we can use compilers to generate the code and automatically synthesize kernels on the fly. And this was a huge thing. And we said, hey, look, we can get performance, we can get things like auto fusion where you merge two kernels together. And compilers are a lot of fun, by the way. I encourage people to learn them. And so that was, that was great fun. Now the problem with this is that where you can't scale kernels by writing thousands of kernels every time you bring up a new chip, turns out AI moves really fast. Turns out compiler engineers are lovely, I love many of them, but there's very few of them. There's very few of them. And so now what you ended up with is you ended up with a bunch of these technologies where it was cool because you could support some compiler for some chip, but suddenly you couldn't do Flash attention or some new algorithm comes on the scene. It's a massive breakthrough in research, but the compiler people couldn't be in the loop to implement the new Sparsity or the new float 4 format, or the new this or that, or the. And so having compiler engineers in the loop was a huge problem and it held back, for example, Google TPUs. A lot of what happened, particularly when Genai came on the scene, really invalidated that technology approach. So I believed. And so going into this, and also part of the learning from working on TPUs is that we needed programmability, we need full power over the hardware. We didn't need the watered down, simple solution that made it so that you got most of the performance. What I believe in is getting all of the performance.

[Podcast Host 2]

Otherwise engineers would just like write kernels as.

[Chris Lattner]

Exactly, exactly. And there's so many technologies, you see this across software where it's like, okay, it works up until a point and then you have to switch to a different system or a different stack. And I don't like those things. Go back to Swift. I wanted to be able to scale from embedded all the way up to application level. Like, like actually unify this. Don't make it so that you have fragmentation in different systems. And so what we bet on was we bet on a two level stack. We bet on Mojo.

[Podcast Host 2]

What programming language?

[Chris Lattner]

A brand new programming language. And as we all know, making a new programming language is doomed and never works. And you cannot get it adopted, all those things.

[Podcast Host 2]

Well, you have a good track record though.

[Chris Lattner]

Yeah, it's actually just a hard problem, but you have to be smart about it. And we can talk about that. And then on top of that saying, like, let's take this programming language and design it so it can solve these problems and scale across hardware, et cetera, but then take these compiler algorithms and put them into the language so that you as a Mojo programmer, get the power of compilers without having to be a compiler engineer. And so a lot of what makes Mojo really special is it takes power out of the compiler and gives it to you as a developer. Because it turns out a lot of people can write code, they can't necessarily write compilers. And so what this does is break, breaks open the talent problem. And so now we can have a lot more people building these very highly adaptive, highly scalable, highly composable systems in ways that they couldn't do before.

[Podcast Host 2]

So can you tell me about both mojo, but. And also how this language can actually break the compiler problem. That part, you know, the new language I think we can all understand, but how you can get through the compilers and get the performance out of it, how does the language do that? Or how does the stuff around it or underneath it do it well.

[Chris Lattner]

So again, this is my life's work, my journey, and so I've made a lot of mistakes along the way. And so a lot of it, as we talked about before, when you don't know what you're doing, go learn from other people and go decide what they've done right and wrong and what you like. For me, a lot of it was learn from what I had done wrong and make sure to do it better the second time. And so one of the things that classical compiler engineers and myself back in 2013, 2005 or something, which is now 20 years ago, somehow. Yeah, was, is that like compiler engineers want to show how awesome their compiler can be. Let me show you. I can implement this optimization, I can detect this pattern. In this case, I can make this code go, you know, two times faster or five times faster, 10 times faster. The challenge with that approach, and this is actually, this is really important for benchmarks, because if you think about, if you're a compiler engineer, you generally can't change the source code. Like, you know, if you're optimizing for the spec benchmark suite or something, the source code's fixed. And so all you can do is implement crazy stuff within the compiler, within the compiler matching and transformations, and maybe change the memory layout of something using some heuristic. But there's a problem for that as a user. And so if you're a programmer and you're using one of these compilers and say you're working with a loop vectorizer, for example, loop vectorization can make your code go four times faster by using SIMD to take advantage of the hardware, Right. But it requires a lot of pattern matching on your code and it has analysis of how you use pointers and all kinds of other stuff that all has to line up for the optimization to work. So now you can have this wonderful moment where you pick up one of these magic compilers and then you get amazing performance and you're like, wow, this is cool. It goes four times faster. I love this thing, this is great. But then you go and fix a bug. If you fix a bug and you break the hack and the compiler, well, suddenly you get a four times slowdown.

[Podcast Host 2]

And you're not sure why, and you cannot really debug it unless you're a compiler engineer.

[Chris Lattner]

Exactly. And so now you file a bug. And again, there's not enough compiler engineers in the world. And so they may or may not look at it, or they may tell you you're holding it wrong. It's too bad. Like, it has to be this way, right? But what that experience is is that's caused by compilers that are trying to be sufficiently smart. And the sufficiently smart compiler never works. What it ends up being is it ends up being an abstraction that's leaky. Leaky abstractions exist in lots of software and lots of different domains, but when they exist in a language it means that you have an unpredictable programming model. So fast forward to today in AI. Today in AI, basically people want peak performance because GPUs are really expensive. As you said, if you build a system that doesn't deliver performance, they'll switch to a different system because they have to, they have to get that performance right. Particularly for the really large scale Frontier Labs and things like this.

[Podcast Host 2]

They need to squeeze everything out of it.

[Chris Lattner]

They need to, it's required. The cost is just astronomical. Otherwise, well, you can't have a system that is like unpredictable or flaky or weird. You want something that has control. And so what Mojo does, unlike Swift and many LLVM languages, Rust, all these guys build on top of the same kind of technologies. We go for a much simpler compiler, it's way more modern, it's way fancier than what like Swift or Rust or languages like that are built on for a variety of reasons, but it's way more predictable. And so it puts control in your hands. And so instead of, for example, vectorization, instead of like hoping to magically do it for you and maybe it works out, maybe it doesn't, it gives you library features where you can say, hey, vectorize this for me.

[Podcast Host 2]

And I saw one of that Mojo, of course there's a tutorial and getting started, I saw there's these special character keywords where if you want to, I mean, you can just like write code that looks like Python, it's a subset of it, and you're like, whatever, but then you can kind of take control, right? So like as a, when you're coding, when you're like, you decide you want a certain compiler feature that it supports, can you give examples of like what I can do with it?

[Chris Lattner]

Yeah, so for example, take simd, S, I, M, D, so vectors even. I don't, I don't think this is even a really standardized feature today in most programming languages. But it's essential to get performance out of a C cpu, right? Most, most of the operations and floating point operations in a CPU are in SIMD because they allow parallelism. So Mojo makes that very NAT native. Mojo also makes things like bfloat 16 and compressed floating point formats and stuff like that, very native. And so it exposes that to you as a programmer. But then you have this problem of you want productivity, like you don't want to have to write assembly code effectively or very low level code to be able to do basic things. And so you want very powerful abstractions that you can build in the library. And so what Mojo does is it has very powerful metaprogramming capabilities. And so, and by the way, it didn't invent these. It roughly stole them from Zig and made them better. So thank you to the Zig people. They have amazing ideas. But the idea is to say, let's pull this compile time metaprogramming system up, make it much more powerful, embed in the language. And so now you can build compile time transformations of your code. And so you can say, hey, I want a vectorized function. Well, what does it do? It takes a higher order function, which is, you know, all the operations you want to vectorize, and then it stamps it out across your vector lanes and it handles that transformation for you, giving you very productive way of expressing these very high performance algorithms that give you extreme predictability. And so this, this design point is very different. It's very important for accelerators because with accelerators you, you can't have memory allocation that magically happens. Like you, you need control. But these, these features are a very different design point than what most languages are coming from. The other advantage, as you say, is it makes the language way simpler. And so if you take a language like C, C has metaprogramming, has templates and constexpr, and like this whole weird system that is, it's a bit evolving.

[Podcast Host 2]

Not the simplest to use. I mean, you, you learn it.

[Chris Lattner]

So like, you learn it and we, I've, I've written way too much C and so like, you know, even I can handle it. But, but what C does is it has the program and then the metaprogram and they're effectively different languages. And so this is really complicated. And writing something using templates, it's almost impossible to debug. You can't even pass a string to a template, really. Like there are hacks, but like, it's just really difficult to do things you certainly can't, like make a binary tree or something and pass it into a template that's not a thing. And so in Mojo nzig, what they do is they unify the program and the metaprogram. And so you can just write code and then run that at compile time. And so now if you want to debug it, cool, just use the same code at runtime and step through it in a debugger makes it super simple. It means you have one thing to learn and it works in both places. It means you can have real types and general types you can do. In Mojo, it's very fancy because you can use like a list or A dictionary kind of data structure that does heap allocations and you can build it all at compile time and then block the output of that into your program. And so it will synthesize the Mallocs for you for a bunch of things. You compile time evaluated and it all composes the right way. And so what this does is it gives you a tremendous amount of power when you care about performance, when you care about building these higher level algorithms which end up being like mini compilers. People generally don't think about it that way, but they give you the ability to specialize based on dimensions and numbers and magic constants in your algorithms and allows you to build these very high, powerful, very high power abstractions very naturally.

[Podcast Host 2]

And if I want to get started with Mojo, outside of just the basics, which are so like using some of these more advanced features, is it the best way to actually rent, may that be a GPU or something these days is pretty easy. And go and try to implement an algorithm, a program that actually needs high performance, and start to play and understand these additional kind of the ways that I can control a compiler. Or what would your suggestion be for someone who is like, okay, Leon believes that this is the future and this is cool to experiment with on their job. They don't currently have a problem like this. How would you go about it on the weekends?

[Chris Lattner]

Right, yeah, I can talk about what, what makes Mojo cool.

[Podcast Host 2]

Yeah, let's, let's do that.

[Chris Lattner]

Well, but see, that ends up in the rabbit hole of really weird technical things that only Chris understands. Wait, let's not talk about linear types. Let's not talk, let's. But instead, let me tell you about why you might care. Okay, so Mojo is a member of the Python family, so it's super familiar, easy to learn, and by the way, with AI coding, it's easiest time ever to learn programming language. Just like you mentioned, One of the simplest easy things to do with Mojo is to extend an existing Python module. So have you ever been coding a Python? Building and building, building. It gets big and big and big and big and suddenly it gets slow. Well, historically your option is to go rewrite a big chunk of it in Rust or C and then you have to use bindings and it's real kind of a pain in the butt to be able to do this kind of work. Mojo is the most beautiful way to extend Python you can imagine. No bindings, just like Swift and Objective C. They natively spoke to each other.

[Podcast Host 2]

Oh yeah, no bindings. Because Rust is a popular choice to extend Python, but with a binding.

[Chris Lattner]

Yeah, but you need bindings, right? Very mechanical and you can get it wrong. And so Mojo does that without the bindings, but also integrated with PIP packages and the build system's all integrated and it's just super beautiful and awesome. And you can stay on cpu. You don't need anything. It's all free. Like, go nuts and go do this. We have very simple.

[Podcast Host 2]

Because I guess one thing with Mojo that I don't think you mentioned, but I know that it's also not just for GPUs or TPUs, but also CPU.

[Chris Lattner]

Also CPUs. And today's CPUs are extremely fancy and complicated machines and getting performance out of them is also really interesting. And so what I've seen people do and come back to the empowering stories that I love. We had a person come to one of our community meetings and they rocked up and it's like, oh, okay, tell us what you're working on. They said, well, I don't know anything about this fancy AI stuff. I am merely a geneticist. And I'm like, merely right. It's like, I work with DNA sequencing and this stuff and I'm a Python programmer. And so I saw that Mojo makes Python go fast. Awesome. And so I said, okay, well, maybe I would try using it from some of my DNA sequencing stuff. And so I pulled over some code and wow, it was like 100 times faster because I pulled it over to Mojo and I could learn how to use threads and then I could vectorize. That I could. It was very cool because.

[Podcast Host 2]

And then you can start to use the CPU's resources if you're running on a CPU, which, as you said, have a lot of capabilities and you can play around with it if you learn how to control the.

[Chris Lattner]

Exactly. And so Mojo makes it really easy to do that where you are on a cpu. And then the thing I loved about it was he said. And then I read that Mojo is really cool for GPUs, and I'd never done that before. I don't know anything about GPUs, but I decided to give it a shot. And in an afternoon I got my thing running on a gpu and now it's a million times faster. And now I'm a GPU programmer, right? And so that, to me is super empowering. And this is where when you look at technologies like Cuda and things like this, again, they're amazing systems and there's a lot of good energy and good work put into it, but it's 20 years old, it's C. It wasn't designed for modern architectures. GPUs today have tensor cores and CUDA can't even acknowledge that that exists, really. And so this is a huge, huge opportunity for us to get more people into the space and for people to learn about this for the first time.

[Podcast Host 2]

I mean, you know, just as an engineer who is like, I don't program GPUs, but of course, like everything I wr Write runs on CPUs or Cloud or wherever. This reminds me a little bit of a story of the. What you previously shared of the Swift person. Because, like, I can't for speaking for myself, I can't really imagine myself like just saying, all right, I'm going to like write Cuda. I don't really have a use case, but I can absolutely imagine myself just like adding a bit of Mojo, optimizing it and then maybe just deploying it on a GPU to see how it is. If I see stuff that are paralyzed, play around with it, is it faster? And then just like with the Genesis.

[Chris Lattner]

Build and learn as you go.

[Podcast Host 2]

Yeah. And then start to understand these other hardwares, which of course will increasingly, probably be useful if we know that. And also they're now available, you can rent them on the clouds. You can soon, maybe not today, but I think even today you can rent.

[Podcast Host 1]

Them by the hour.

[Chris Lattner]

Yep, that's right.

[Podcast Host 2]

If not, it's going to happen for sure.

[Chris Lattner]

Yeah, you can totally do that. Well, and so we even go further. It turns out that lots of things have GPUs today with Mojo, you can run on AMD, Nvidia and Apple GPUs. And so if you do want to learn about GPUs, you can go to our website, search for GPU puzzles, and we'll teach you how to do this. And actually, it's an amazing task. I love it because what we're doing, and we're still early, we're still building into this and we'd love help. Please come join our open source community and help us build into this. But what we really, truly believe is that GPUs and AI accelerators and all these chips, whether they're for AI or for DNA sequencing or chemistry or bioinformatics or oil and gas exploration, there's all hpc, there's all these applications that can use these, these accelerators, but all the software around them is really weird.

[Podcast Host 2]

Right.

[Chris Lattner]

And if we can, if we can break that down, if we can make it easy to learn, if we can teach people, if we can make them consistent across the hardware vendors, because these hardware people don't always get along, by the way. But if we can make it more uniform, then we can get a bigger community in that community. Sure, some of the people, some of the old dogs from the existing community will convert over and we love that. And you know, Mojo's way nicer than C and so it's way better from a user experience perspective and compile times. And there's so many things that are better about it than older technologies like Cuda. But also what I believe is that there's an entire new generation of people that should be programming these chips. And if we can get more people into this ecosystem, they can upscale, they can get better jobs. Like these are high paying jobs to do this kind of work. And so it's the best time, it's a better time than ever to learn how to do this. And so it's, you know, personally my life's work here is to enable this and enable people to get into this ecosystem and break down the gatekeeping.

[Podcast Host 2]

And really, it really feels you have been just always been passionate about compilers, technology and going towards here. Can you tell me where Modular is as a team? You started about three years ago. Can you tell me how much progress you made, how large the team is right now and where Mojo and the ecosystem is and where you're focusing next?

[Chris Lattner]

Yeah, so Modular will be four years old in January. It's hard to believe. Turns out things do take four years sometimes even with full focus. Yeah. And so we are an unusual startup and we went into this knowing this, but we are a very large team and very expensive because we believe, and our investors believe that this problem that we're tackling is very important. And so at this point we're about just over 140 people, something like that. And we've enabled seven different architectures from three different vendors. So that's Ampere, Hopper, Blackwell from AMD or from, from Nvidia. The 300, 325, 355 from AMD, plus all their consumer stuff. And now Apple GPUs and beta and coming online, which is very exciting. We're probably not done yet. We'll keep going, but can't share stuff before it's time to share. But it's still very early days. And so what we're doing is we're building into this from a technology perspective. Mojo, for example, I want 1.0 to be meaningful. And so I think that we'll have 1.0 early summer next year, so that'll be pretty cool. And it will be way better than Swift 1.0.

[Podcast Host 2]

Yeah, but I was about to say, like this 1.0 will be so.

[Chris Lattner]

So the team's scoping that out. We'll come up with detailed dates soon and we'll share that when it's the right time. And so as we're doing this, what we're doing is we're being really thoughtful and learning from the previous, my previous journey and from other people on the team's journeys to make sure that we do this well. And so we want to provide stability for the ecosystem, which swiftone didn't do, by the way, and build into this. And each time we do pass through one of these milestones, we can expect more growth and more use cases and more investment from different kinds of people. That's what I've seen. So commercially we have customers and we're scaling into that. We have a cloud platform which is the way we monetize most of this stuff. Mojo is not a product that we're trying to make tons of money on, by the way. It's a thing we had to build to be able to scale across lots of hardware. And so we see a dual world where we can actually catalyze and grow and teach people how to build and use all these accelerators and then we can help enterprises build and manage AI into their ecosystem. And a lot of what these folks are looking for is they want something that's easy to use, that actually works, that's reliable, that they can scale. Yeah. A lot of them want optionality on hardware. They want to be able to buy the best chip for their workload, they want to be able to get multi source in different vendors. They don't want to have to rewrite it three times.

[Podcast Host 2]

Yeah, I mean, this all only makes sense when you're especially that there's this dependency on like one or two vendors. Usually one.

[Chris Lattner]

Yep. And so, and what I've. What I see and what I predict in 2026 is there's going to be a lot of silicon from a lot of different vendors and we want to make sure that people can scale across that effectively. And so, you know, for people that are interested, we have lots of job postings on our website and so we're growing very rapidly and we have a very big mission. It will take, you know, it's not another six months and then we're done. We're just still at the beginning and every year of our journey is just another epoch of new things to build and learn and grow and develop into this.

[Podcast Host 2]

And of course, you're building like your. Sounds like the infrastructure under AI, or hopefully a lot of it could be. How is your team, the engineering team, specifically using AI AI tools, may that be IDs? Agents, you mentioned that Mojo is a pulmonary language to write with AI, but I'm interested underneath the hood, are you seeing the impact of these tools? Is it helping engineers work faster or down in the current? Because there's always this question, like, if you're writing compilers, will these things help at all or no, you need to handcraft it. And I'd love to ask for someone who's actually seen it.

[Chris Lattner]

Yeah, well, so I can tell you, I can't tell you all the things, but I can share my experiences. So we definitely encourage our team to use AI coding tools and so use Claude code and cursor and all 57 other things. And so there's lots of different experiences. I saw, I've seen tons of benefit. And so for me, I still code. And so I use cursor, for example, as my daily driver right now. And so I feel like it's, you know, a good 10% productivity for particularly mechanical rewrites and stuff like this.

[Podcast Host 2]

But you're a really good programmer, so that's pretty good, Pretty meaningful.

[Chris Lattner]

Yes, I represent very sophisticated programmer, correct? Yes. And so, like, I. But it's really. I enjoy it because it frees me from a lot of the mechanical stuff. And so whether it makes me aggregate more, more productive or not increases my enjoyment, which is good.

[Podcast Host 2]

It's really important.

[Chris Lattner]

It is actually. Now, for other folks that are building prototypes or pms that are building like wireframe models of things, it's transformative because you can literally 10x somebody and you can make it so they could build something that otherwise wouldn't get around to doing. And so that is transformative for production coding. I think it's kind of hit and miss. And to me, honestly, I don't know if it's like actually a net win or not, because I've seen many cases where people say, okay, just go, go. Let the agent, like try a thing. And then it grinds and grinds and grinds and a gajillion tokens later, like, it doesn't work. If they would have just done it, then it would have been done sooner. Right. And so to me, like, again, there's lots of wins, but there's also some losses. And so I don't know how things will net out. I do know it's moving Very rapidly, and I do want us to be using it. But also one of the things I'd say is I don't want people to turn their brains off. And one of the things I think is really important is that programmers in our team, but also in general, they use it as a human assist, not a human replacement. And I think it's very important that we review the code, we understand the architecture, and it's not kind of for production workloads and production applications, at least. Vibe coding terrifies me, not just because of what does it mean for jobs, but. But what does it mean six months from now when you want to change the architecture of something? How are you going to even understand how anything works? Right? And so I do think that it's really important to keep humans in the loop and architects thinking about something and understanding things, not just for security and performance and all the other reasons as well.

[Podcast Host 2]

Well, Adi Osmani, I talk with Adi Osmani, who's been on the Chrome DevTools team for like 13 years now. I think a lot of the. The tooling he or his team built there. And he said, he wrote this book called Beyond Vibe Coding. And he said that what he does is he enables a verbose kind of output for the agent and he actually reads through what the thing was. He makes sure that before he commits something or reviews that he just understands what they're so that he always stays in touch. So if this thing turned off, he could jump in. It's just like he had now. He just chose not to do so well.

[Chris Lattner]

And I think that again, the thing that I care about is that, that the architecture of production, I mean, prototypes are a different deal, but for production, you keep the architecture clean and right? It doesn't need to be perfect, but it needs to be curated. Because I've seen AI coding tools go crazy with like duplicating things in different places. Well, we know that's a problem because then you want to go change something. Now you have bugs when you update two out of the three places, right? And so there's a lot of these things where the tools are amazing, but they still need adult supervision.

[Podcast Host 2]

So when it comes to hiring, you're building something really interesting and cool and honestly, super ambitious. You already have a pretty big team, but you're growing. What is your hiring bar? And I think you previously mentioned that you're building a company of elite nerds. I'm interested, not wrong. What are things that you look in, folks? And for software engineering, experienced engineers especially, listening what tactics or Strategy would suggest that they get to the level that they could have a shot at a place like Module or even if not, not necessarily modular.

[Chris Lattner]

Yeah. So we hired two different kinds of folks. One is the super specialized, you know, compiler nerd or something like this, or the GPU programmer expert that knows how to do high performance matrix multiplications and they've got 10 years of experience and so you can go look at that track record. We also hire people fresh out of school.

[Podcast Host 2]

Wow, this is refreshing.

[Chris Lattner]

And so I really do appreciate people that are very early career because they haven't learned all the bad things yet.

[Podcast Host 2]

It.

[Chris Lattner]

And so for me, I think maybe more interesting thing to talk about is not the super expert that's already the senior engineer.

[Podcast Host 2]

Yeah, we are.

[Chris Lattner]

It's about folks that are much earlier in their career. And so what I love to see is I love to see people that are really hungry, that have not given up and just said, AI will do everything for me. But they have intellectual curiosity, they're willing to work hard, of course.

[Podcast Host 2]

Right.

[Chris Lattner]

But then they're fearless because everything, particularly in the AI space is changing so rapidly. But a lot of people just freeze up and they won't do anything versus if you say, okay, cool, let's go figure it out. I want to learn how to do this. I mean, this has been my life's journey is just. It has. That sounds terrifying. People tell me it's impossible and it's doomed to failure, but how hard can it be? Let's just go figure it out and work through things and do that. And I personally really love when people have contributed to open source projects. I think that's the simplest way to prove that not only can you write code, but you could actually work with a team, which is a huge part of software engineering in reality. And so I love internships and things like this that people have done before. And kind of when talking with people, you can tell whether they're excited about what they do or whether they're just kind of performatively kind of going through the motions. Now one of the really challenging parts is in interviews, people get very nervous. And so one of the things I really believe in is giving people kind of the native tools they're used to using, and so let people code in the way that they would be normally coding. And so today, for example, we want people to be using AI coding for the mechanical pieces. Right. So saying, okay, well you have to write in a whiteboard and you can't use your native tools would be very strange. And so we kind of try and make sure to meet people in something that actually approaches a real world situation.

[Podcast Host 2]

One question I've been meaning to ask, because you built several languages, this comes up and I asked folks like, what are things they'd love to hear from you? And this was repeated quite a bit. Do you think there is any logic in having a new language that is designed to make it easy for LLMs to code with and like attributes? For example, better pattern matching or other things that might be the strength of LLMs? And if so, like, what would these patterns be?

[Chris Lattner]

This is really weird.

[Podcast Host 2]

I would have not thought we would talk about things like this, but now we should.

[Chris Lattner]

Absolutely, I'm happy to talk about it. And so I often sometimes get asked, so given the AI is writing all the code, why are you building a programming language? Which is another way of asking the same question, maybe a little bit more aggro. And so to me, I don't think that optimizing for the LLM is the right thing to do at all. Because go back to what we were just talking about. The important thing is reading the code. Always has been, by the way.

[Podcast Host 2]

Right.

[Chris Lattner]

Code is read more often than it's written. AI has made it way easier to crank out the code than it ever has been. And I don't think we're going back.

[Podcast Host 2]

To where we were.

[Chris Lattner]

So writing the code is actually not the key thing to me, it's about reading it. And so what I care about with Mojo and with these new emerging systems that we're building is really a combination of two things. One is expressivity. And so can you express the full power of the hardware, yes or no? Like, if the answer is no, then you will never be able to get it. So JavaScript will never be a good way to write a CUDA kernel or a GPU kernel. Like, it just will not. Because it can't express the things you need to express. Right, right. No slight against it. It's a good system. Right. But if that's the goal, then you have to be able to do that. Now, assembly code can express the full power of the hardware, and that's not what I'm advocating for. Right. The other thing that goes with it is you need readability. And so you need this combination, this intersection between expressivity. So can you express the important thing in our case performance? And then can you understand the code? Can you build abstractions, can you build scalable systems? And that intersection, I think, is the key thing. And so this is where you take Python syntax, for example. Python's super easy to read. It's actually very standard. A lot of people know it. Let's embrace that. Let's go all in on that. That's a good thing. And so Mojo embraces Python and the syntax of Python at least, and says, okay, well now let's fix the problems with Python, which is basically the entire implementation. Let's replace the Python interpreter and all that kind of stuff. Let's keep this good part and make it so we can express that full power of the hardware. And with that, I think the LLMs will continue to get better and better at dealing with any weirdness. And what I've seen is that the LLMs are an amazing way to learn coding a new language.

[Podcast Host 2]

Yeah. This is interesting because I feel we're starting to see including in how to build good software. Oftentimes what is good and efficient for teams is also LLMs tend to do better with them.

[Chris Lattner]

Yeah, I also get these funny questions. It's like, okay, well, a lot of people in the agentic coding loops want to have error messages that feedback into the agents so that the agents know what to do. And so should we make better error messages for the agents, make it better for humans? And my question is like, what? What is better for an agent that's not al. Also better for a human? Let's just have good error messages.

[Podcast Host 2]

Right.

[Chris Lattner]

The other key thing, and I think the most important thing for LLM based coding and AI tools is have a massive amount of open source. And so for us, if you go to the modular repo, we have, I don't know, 700,000 lines of mojo code that's open source.

[Podcast Host 2]

And when you open source that you open source the whole history as well, by the way.

[Chris Lattner]

Exactly, exactly. And so that's super powerful because now you can say, hey, hey, go index this. And so now it knows a gigantic swath of everything you can possibly do. And so that I think is also really important.

[Podcast Host 2]

Yeah. Now, to close with, you have mentioned that compilers are cool multiple times here.

[Chris Lattner]

I'm slightly biased, I admit.

[Podcast Host 2]

Absolutely. But I'm getting convinced that compilers are cool. For software engineers who have not built or worked with compilers, what are some kind of pointers you would give them of like, hey, I'd like to get into understanding compilers, maybe building one. Should I try to come up with a language? What are some things that you point people to?

[Chris Lattner]

Yeah. So I'll tell you why I fell in love with compilers. So if I go back to university, I was taking the standard computer science program of basic programming, then data structures and then an operating system class and GUI class and, and all this kind of stuff. The thing I love about compilers is that you built Project one, and so in this case it was what's called the Lexer, the thing that tokenizes the source code and you had to use some data structures. So I'm like, oh, okay, cool. I'm using the things I learned, not just how to write code, but what a tree is and things like this. And then you get to the second part and you build on top of it. And so now you build a parser, the thing that decides the syntax of the language using the tokenizer, and then you build the type checker and you build on the first two and then you build the next thing and you build on those things. And so what I loved about compiler as a class was that I got to build and learn and iterate, and then if I made a mistake, I had to go back and fix it as you're building higher and higher and higher. And so I think that compilers, particularly in the university setting, reflects more of like real software development in a way that a lot of other classes I experienced did not, because a lot of the other classes ended up being build a thing, turn it in, throw it away, build another thing, turn it in, throw it away. And so that's why I fell in love with it. Today, if you want to learn compilers, it's easier than ever. You can go to llvm. There's a great tutorial called the Kaleidoscope Tutorial that I wrote.

[Podcast Host 2]

How wonderful.

[Chris Lattner]

15 years ago or something. It's been a long time ago. The Rust community has a lot of lovely compiler nerds in it, and so a lot of compiler based technology is built in Rust these days, which is also super cool. And so there's books and lessons and things like this. I don't literally think everybody needs to become a compiler engineer, but I think the compilers don't get the credit they deserve. And it turns out there's a lot of really good jobs in compilers. And so if it happens to be that it's an interesting place and interesting set of technologies, and I really do encourage people to do it because we need more folks in this field.

[Podcast Host 2]

Wonderful, Chris. This has been really, really interesting. Learned a lot.

[Podcast Host 1]

Thank you.

[Chris Lattner]

Yeah, well, thank you for having me. I hope it was useful.

[Podcast Host 2]

It was.

[Podcast Host 1]

It's rare to talk with a software engineer who is so passionate about programming as Chris is, and I hope you enjoyed this conversation as much as I did. I especially liked how Chris took us to the backstage of how things really happened at Apple, how it was Chris's own stubbornness and track record of getting things done that allowed him to push things through, like open sourcing the Swift programming language and creating the new language to start with.

[Podcast Host 2]

For more deep dives on AI engineering.

[Podcast Host 1]

And stories and developers or tools at other companies, check out Deep Dives into Pragmatic Engineer that I wrote linked in the show Notes below. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show. Thanks and see you in the next one.