Lattner Aims Mojo at AI Accelerators to Bypass LLVM Code Ceilings

拉特纳让Mojo瞄准AI加速器以突破LLVM代码性能上限 克里斯·拉特纳指出，由于共享老化的LLVM后端，现代系统级语言遭遇了相同的性能瓶颈，因此需要一种将Python易用性与裸机加速器硬件融为一体的新型编译器架构。 克里斯·拉特纳详细梳理了现代系统级编程的演进历程，回顾了他在研究生时期主导的LLVM项目如何逐步成为支撑Clang、Swift和Rust等语言的底层基石。他分享了Swift在苹果公司秘密研发背后的历史与内部运作策略，并将其渐进式展开与向后兼容的采用方式，与Python 2痛苦的迁移过程进行了对比。在探讨语言范式时，拉特纳批评纯函数式编程与物理CPU缓存架构存在冲突，并主张采用值语义。最后，他概述了创立Modular和打造Mojo的愿景，阐述了碎片化的AI加速器调用链以及LLVM后端的局限性，为何促使他们构建一款可扩展的“Python++”，以超越英特尔MKL等经人工调优的高性能库。 克里斯·拉特纳解释称，Modular在开发出能够在英特尔硬件上超越英特尔数学核心函数库（MKL）的内部编译器和异步运行时之后，催生了Mojo，因为最初的技术栈仅有三名工程师懂得如何编程，迫切需要一个Python风格的前端。 (59:25) Rust、Swift和C++等主流编译型语言从根本上受制于相近的性能上限，因为它们完全依赖于拥有20年历史的同一套LLVM后端基础设施。 (61:41) Swift之所以能在Python 2向Python 3转型失利之处取得成功，是因为它优先保证了与Objective-C、C和C++的无缝双向互操作性，避免了整个苹果生态系统中出现大一统式的强行代码迁移。 (13:22) Mojo直接借鉴了Zig语言comptime模型的整套编译期元编程系统，同时保留Python语法，以此来统一涵盖CPU、GPU及定制加速器的AI基础设施。 (64:10)

## Background 本期视频由 YouTube 频道 The PrimeTime（主持人为 ThePrimeagen）于 2024 年 7 月 12 日发布，内容录制自其 Twitch 直播平台。视频特邀 LLVM、Clang、Swift 的发明者及 Modular/Mojo 联合创始人 Chris Lattner 与技术博主 TJ DeVries 进行深度对谈，围绕现代编译器演进、大型项目推进与 AI 时代底层设施重构展开。 ## TL;DR 访谈回顾了 Chris Lattner 从读研期间在 UIUC 孵化 LLVM，到在苹果内部顶住阻力秘密研发并推出 Swift 的传奇历程，深度拆解了通过混编互操作化解兼容性危机的工程哲学。随后，对话切入对函数式编程与硬件现实冲突的尖锐反思，并对比了 Go、Rust 与 Swift 等语言在复杂度控制上的得失。最后，Lattner 详述了创立 Modular 并打造 Mojo 的核心逻辑：抛弃对传统 LLVM 体系的盲从，构建全新编译器技术栈以彻底释放现代硬件算力，消除 AI 底层基础设施的技术泥潭。 ## Atmosphere & style 整个访谈弥漫着硬核黑客间无拘无束的幽默感与技术狂欢氛围，ThePrimeagen 和 TJ DeVries 接连抛出密集的梗与尖锐提问，而 Chris Lattner 则以罕见的直率与松弛感从容应答。现场既有当着镜头毫不留情调侃“原教旨函数式编程脱离现实”引发的哄堂大笑，也有对苹果高层博弈、系统级架构抉择等深水区幕后故事的严肃剖析。听众能直观感受到顶尖系统架构师对计算机底层规律的绝对掌控力，以及经历无数次被看衰后依然推陈出新的从容与霸气。 ## Bulletin - [02:37](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=157s) Chris Lattner 透露，Rust 等基于 LLVM 的语言能够实现尾递归消除并转换为 for 循环，源于他 21 年前在研究生阶段向 LLVM 硬编码的核心算法。 - [18:50](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=1130s) Swift 在 2014 年 WWDC 发布前经历了长达 4 年的保密研发；即便发布时，苹果内部数万名工程师中仅约 250 人知情，近 90% 的内部员工同外界一样被突如其来的发布所震惊。 - [56:55](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=3415s) Modular 创办的核心假设在于“编译器的通用性优化能够超越人类针对单一场景的手写汇编”，其全新的编译器与异步运行时在 Intel 硬件上的矩阵乘法性能已成功超越手写优化的 Intel MKL 基准。 - [58:33](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=3513s) Mojo 并非为了发明语言而凭空构想，而是团队为一套基于 MLIR 理念重写的高性能异构计算编译器寻找的前端语法外壳，其编译期元编程系统深度借鉴了 Zig 的 comptime 机制。 ## Key takeaways - [00:00](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=0s) LLVM 的诞生始于一次学术界“书呆子狙击”（nerd snipe），Chris Lattner 原计划仅在 UIUC 读一年硕士，却因被导师引导至编译器研究而留在学术界攻读完博士。 - [02:37](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=157s) Rust、Swift、Julia 和 Clang 等现代编译器架构直接免费继承了 Chris Lattner 早期在 LLVM 留下的核心代码遗产，至今他依然是 LLVM 代码提交行数最多的贡献者。 - [04:06](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=246s) Swift 研发前一年半仅为 Chris Lattner 调节压力的夜间与周末业余项目，其早期推行的核心组织阻力在于资深管理者对自身 Objective-C 专业知识“被清零”的心理恐慌。 - [11:02](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=662s) 苹果破例允许 Swift 在发布初期打破向后兼容性，这为管理层提供了一个非“单向死门”的决策泄压阀，避免过早将未成熟的语言设计焊死。 - [13:21](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=801s) 相较于 Python 2 到 3 因单体全量升级导致长达 15 年的迁移阵痛，Swift 凭借与 Objective-C 底层的无缝双向互操作性，允许开发者逐个类渐进替换，从而在更短时间内完成了整个生态的彻底平移。 - [18:50](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=1130s) 严苛的保密机制让苹果在关键技术转型中避免了成千上万名工程师的无休止扯皮，通过极少数高层决策者的集中拍板推动激进的颠覆性变革。 - [21:16](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=1276s) Swift 后期演进未能贯彻“复杂性的渐进式暴露”原则，在极速获取 PMF 的压力下堆砌了大量特化语法糖（如 SwiftUI 结果构建器），导致编译器性能下降且语言规范臃肿。 - [28:28](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=1708s) Go 语言在泛型引入上展现了极其审慎的克制，通过“测 200 次再切一刀”的长期工程观察，最终在保持极简主义主线的同时交付了高质量的泛型体系。 - [32:06](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=1926s) 严格定义的纯函数式编程与现代物理硬件严重脱节；物理计算机本质是“一大袋可变状态”，禁止就地修改而强制全量复制深拷贝的做法在现代大规模高吞吐系统中无法扩展。 - [35:12](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=2112s) 值语义在系统编程中展现出对纯函数式的降维打击：它既能提供行为隔离与无别名安全，又允许底层直接进行就地内存覆写，兼顾了表达力与物理硬件效率。 - [38:05](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=2285s) Mojo 明确将成为“Python++”作为其核心愿景，旨在终结上层 Python 胶水语言与底层 C/C++/CUDA 割裂的双语言困境，实现全栈统一编程。 - [41:35](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=2495s) Mojo 与 Python 的互操作并非重复造轮子，而是直接通过稳定 C API 调用标准 CPython 解释器，零成本享用社区在多线程与无 GIL 等底层设施上的演进红利。 - [50:57](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=3057s) 巨头科技公司的资深工程师往往精于在庞杂系统内做爬山式局部优化，却在面对“从零构建”一张白纸时因缺乏边界界定能力而陷入集体瘫痪。 - [54:29](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=3269s) 当前运行 AI 任务的底层系统软件栈是由 CUDA、MPI 等碎片化拼凑而成的巨大灾难，异构计算硬件的爆发迫切需要一套通用的编译器底层平台来终结重复造软件栈的困境。 - [01:01:41](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=3701s) Modular 并非仅在 LLVM 之上简单打包，而是从零重写了一套整合 MLIR 先进理念、异步运行时与自动算子融合的全栈编译器，以此打破现有代码生成器的性能天花板。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=0s) 欢迎 Chris Lattner：LLVM 的起源与学术界“书呆子狙击” 主持人 ThePrimeagen 开门见山地宣布这一期节目为“Top Shelf”高规格访谈系列，专门邀请对行业产生深远影响的顶尖技术嘉宾。本期请来的是 Chris Lattner——作为 LLVM、Clang、Swift 的发明者以及如今 Mojo 的主导者，他的工程产出深刻地影响着全球数十亿开发者的日常开发与计算机底层设施。ThePrimeagen 调侃道，弹幕里的观众最感到不可思议的两件事，一是 Chris 居然拥有博士学位（博士在很多观众眼里简直像不存在的神话），二是他拿了博士居然没留在学术界天天写 Haskell。 谈及这段学术生涯，Chris 坦言自己在伊利诺伊大学厄巴纳-香槟分校（UIUC）念研究生时虽然玩得很开心，但他其实并不擅长写论文或做一个纯粹的学者，他真正着迷的是“有人付钱让我去造我想造的东西”。至于为什么读了那么多年书，Chris 笑着爆料，他最初去伊利诺伊的目标其实非常简单：读一个一年期的硕士学位，拿完文凭就赶紧走人。然而，他的导师 Vikram Adve 成功对他实施了“书呆子狙击”（nerd snipe），抛出了 LLVM 这一研究方向。Chris 一头栽了进去，觉得太有趣了，最终决定留下来攻读博士。他戏称整个 LLVM 项目的诞生和发展，“完全就是史上历时最久、规模最大的一次书呆子狙击”，甚至打趣道“这全都是导师的错”。 - Chris Lattner 拥有计算机科学博士学位，就读于伊利诺伊大学厄巴纳-香槟分校（UIUC），其博士导师为 Vikram Adve。 - 他在研究生院原本的计划是只花一年拿完硕士学位走人，却因被导师引向 LLVM 的研发而彻底改变了职业轨迹。 - Chris 阐述自己的工作驱动力：“我不单单是因为在理性上想要达成某个目标而工作，更因为我爱上了这个难题本身，对它充满热情。驱动这一切的是热情，而不仅仅是‘出于某种原因这个难题必须以这种方式被解决’的理性权衡。” ### [02:37](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=157s) 编译器的代码遗产：从大学项目到 Rust、Swift 与 Julia 的共享红利 ThePrimeagen 和 Chris 聊到了现代语言中许多看似神奇的编译器优化。Chris 提及不久前团队写过一篇关于“Mojo 为什么比 Rust 快”的博客文章，当时引来了大量 Rust 开发者的质疑。反对者们争论说 Rust 的底层能力极其强大，拥有尾调用优化，甚至能将尾递归函数直接转换为 `for` 循环。 Chris 忍俊不禁地指出，大概 99% 的评论者并不知道其中的底层真相：Rust 能够搞定尾递归消除并将其重写为 `for` 循环，纯粹是因为 21 年前一名在读的大学研究生（也就是 Chris 自己）偶然冒出一个算法构想并把它硬编码进了 LLVM。如今，Rust、Swift、Julia、Clang 等一大批采用 LLVM 作为后端的编程语言，都直接、免费地继承了他当年敲下的算法成果。面对主持人“所以你是 Rust 最核心的性能贡献者之一”的调侃，Chris 回应称，直到今天，他依然是整个 LLVM 及其全部子项目中绝对贡献行数最多的第一大提交者。 “几乎 99% 的人，或者至少是那些发表评论的人根本不明白，Rust 能够做尾递归消除并转成 for 循环这种骚操作，完全是因为 21 年前一个大学在读生突然想到了一个算法并将其实现进了 LLVM，这才有了今天 Rust 的这一特性。” —— Chris Lattner ### [04:06](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=246s) Swift 的孕育史与苹果内部的阻力 联合主持 TJ DeVries 将话题转向苹果时期的内部变革。TJ 指出，对于很多习惯甚至深爱 Objective-C 的老派程序员而言，推行一门全新的语言必然伴随着强烈的抵触情绪。他们经常会质疑：“我写 Objective-C 的时间可能比某些新人的年龄都长，为什么非要搞一套新玩意？”TJ 询问 Chris，在苹果这样体量的公司内，是如何跨越技术和人性的阻碍推动这一变革的。 Chris 首先拆解了 Swift 早期的关键时间线： 1. **2010 年**：项目启动，最初纯粹是他个人的“夜晚与周末业余项目”（nights and weekends project）。 2. **2010—2011 年半**：长达整整一年半的时间里，全苹果没有任何人知道 Swift 的存在，只有他自己在一行行摸索。 3. **2014 年**：Swift 在 WWDC 上正式向全球发布。此时尽管已经秘密开发了四年，全苹果知晓该项目的人数也仅控制在约 250 人左右。 4. **2016 年**：Swift 宣布正式开源。 Chris 回忆，他在苹果白天的主职是管理几个极其庞大的核心工程团队。当时他正带领团队在 Clang 中攻克极其棘手的 C++ 编译支持，包括让编译器自举（bootstrap）以及构建极其复杂的 Boost 库。实现 C++ 是极其磨人的工程苦差，Chris 笑称干完这一票的人“很难不患上某种创伤后应激障碍（PTSD）”。因此，在业余时间琢磨一门干净的新语言 Swift，成了他调节精神压力的减压阀（relief valve）。当个人原型初具雏形后，他凭借以往连续交付重要成果所积累下的深厚工程信誉，向管理层展示了原型；管理层虽然觉得有趣，但最初仍认为有其他更优先的事项，直到后来才批准他私下抽调几位手下的工程师参与进来。 ```mermaid flowchart LR accTitle: Swift 早期演进路线图 (2010-2016) accDescr: 展现 Swift 从 Chris 的业余项目到向公众开源的四个关键阶段 subgraph Phase1["秘密探索期"] A["2010: 夜间与周末业余项目<br/>(仅 Chris 1 人知晓)"] B["2011: 验证可行性<br/>管理层准许内部小范围探索"] end subgraph Phase2["内部攻坚期"] C["2013: 关键决断点<br/>高管严苛评审 / 升级为官方级投入"] D["2014: WWDC 正式发布<br/>(全苹果仅约 250 人知情)"] end subgraph Phase3["开源生态期"] E["2016: Swift 正式开源"] end A --> B B --> C C --> D D --> E ``` ### [06:58](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=418s) 关键决策点：“为何不直接修补 Objective-C？” 在 Swift 启动约三年后（即 2013 年前后），项目迎来了真正的生死关头：苹果是否要为其投入巨大的公司级资源。Chris 强调，发布一门真正的编程语言绝非写一个编译器那么简单，它是一项涉及全套工程基建的宏大工程——必须同步配套官方书籍文档、深入 Xcode 的 IDE 集成、开发专属调试器（LLDB 工具链）、重新设计整套优雅的 API 等。为此，苹果执行层展开了一系列极其严苛的高管评审（executive reviews）。 在评审会议上，高管们抛出了两个最致命的战略质问： 1. **生态分裂风险**：一旦推出全新的语言，是否会将现有的苹果开发者生态直接割裂成两半（一半支持 Swift，一半坚守 Objective-C）？ 2. **存量替代难题**：“如果 Objective-C 存在种种缺陷，为什么我们不能直接修补 Objective-C？” 面对第二种业界最典型的质疑，Chris 和团队采取了务实且高明的“双向牵引”策略：他们公开赞同并着手全面改良 Objective-C。团队给 Objective-C 陆续增加了现代化的语法字面量（literals）、模块化机制（modules）以及划时代的自动引用计数（ARC）。这些特性一方面极大缓解了现有开发者的痛点，另一方面更为 Swift 的平滑铺路：通过模块化机制与 ARC 的内存管理规范，为未来 Swift 与 Objective-C 庞大历史 API 的无缝互操作提供了底层契约。尽管如此，在面对资深技术管理层抛出的一系列无法证伪的玄学难题（例如“你怎么能证明新语法真的比原来好”、“万一有人就是不喜欢这个语法糖怎么办”）时，团队仍面临着严峻的沟通与说服挑战。 “如果你想要发布一门编程语言，这可不仅仅是写一个编译器那么简单。你必须配备一本书、实现 Xcode 深度集成、打造专属调试器、设计出真正美观易用的 API——要做好这一切，需要的是庞大得多的资源承诺。” —— Chris Lattner ### [09:21](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=561s) 破解“归零恐惧”：向 Objective-C 老将推销 Swift Chris Lattner 回顾了他在推行 Swift 时遭遇的核心阻力：当时苹果公司内部几乎所有的软件工程师，都是伴随着 Objective-C 成长并因此加入苹果的。许多资深软件领导者早在十五年前就曾在 NeXT 工作，他们的整套职业生涯都建立在 Objective-C 之上。对他们而言，Objective-C 毫无问题——庞大的开发者社区由此建立，iPhone 的辉煌也源于它对“动态面向对象特性”与“C 语言性能和底层能力”的绝妙结合。高管们最直截了当的反问就是：“既然它没坏，你为什么要修？” 更为致命的心理阻力在于，这些老兵早已身居管理高位，脱离日常编码多年；如果苹果推出一门全新的语言，实质上是将他们的核心专业知识彻底“清零”。Chris Lattner 坦言自己有时“反应比较迟钝，与人打交道并不算强项”，但他一旦想通了这一点，就立刻停止了纯技术层面的工程师说辞，不再纠缠于“为什么新语言不需要分号”之类的细枝末节，而是转入心理安抚模式。他向管理层证明，过去的知识完全可以无缝迁移：现有的 Framework、API 设计模式与架构经验都将被全盘保留。通过将 Swift 映射进资深团队原有的价值体系中，这些老将不必被淘汰，反而依然能在变革之旅中扮演核心英雄。 ```mermaid flowchart LR accTitle: Swift 内部推行阻力与破局策略 accDescr: 展示了资深工程师对经验归零的担忧，以及通过保留 API 架构并赋予英雄角色的破局过程。 subgraph Conflict["核心心理阻力"] A["高管脱离编码多年<br/>职业根基源于 Obj-C"] --> B["推出全新语言<br/>专业知识归零风险"] end subgraph Solution["破局安抚策略"] C["停止争执语法细节<br/>（如去除分号）"] --> D["全面保留 API 体系与设计模式"] D --> E["让老兵在转型中<br/>继续担当核心英雄"] end Conflict --> Solution ``` - Chris Lattner 总结自己转变沟通策略的顿悟：“And so what Swift represented was a reset of their expertise back to zero and so I'm a kind of a dense person people are maybe not my strong point but um but once I realized that suddenly it became like don't go engineer brain on uh this is the way this is why we not going to require semic colons or whatever right instead go into reassuring like this is why it's going to be okay this is why everything will transfer over we'll keep all the APIs blah blah blah blah blah we'll keep everybody you know the the important thing is the design patterns from the Frameworks and the APIs and like all those come over without change and and I was able to find a way to explain it a way that mapped into the value system made it so that people um even people much more senior than me would be heroes in their Journey still and be able to do that and that that's one of the things that allowed it to get through.” --- ### [11:02](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=662s) 打破苹果常规：以“允许破坏兼容性”作为安全泄压阀 在 Swift 临近发布的阶段，另一个巨大考验随之而来：当时整个语言实质上仅由 5 到 10 个人的核心团队打造，即便加上向 Chris 汇报的员工，全公司内部见过它的人也不过 200 左右。大家普遍感到焦虑与恐惧：“我们怎么保证它是优秀的？一旦向全世界发布，万一搞砸了岂不是奇耻大辱？” 苹果历来的产品发布传统是向开发者承诺极高程度的向后兼容保护，绝不轻易破坏现有生态。但 Chris 意识到，如果为了追求稳定性而过早将这门仅在数百人圈子内测试过的语言“焊死”，后果不堪设想。他提出的突破性解决方案极为反常规：直接告知外界这门语言不会保证向后兼容性。苹果允许开发者在 App Store 提交 Swift 代码，但明确声明后续版本一定会破坏旧代码，因为开发团队需要大量的实际里程碑和社区反馈来真正打磨语言。这种坦诚打破了管理层的僵局：它为管理层提供了一个绝佳的“泄压阀”——开发者可以自由选择保留使用 Objective-C，如果 Swift 出现差错也不至于把整个公司带入万劫不复的“单向死门”。 此外，促使 Swift 获批的技术杀手锏还包括跨越 Objective-C 底层限制的内存安全机制（在 Objective-C 中彻底移除裸指针是不可能的），以及它能与 Xcode 紧密结合打造出高附加值的开发体验。 - Chris Lattner 回忆说服管理层的关键破局点：“And so the breakthrough was when I realized look let's just tell people it won't be compatible like Swift you can use it you can submit it to the App Store we will break your code because we have not gotten a lot of miles on this thing our goal is to make this good not just nail it down and once I once we got through that then exact leadership was like oh well okay well if we're clear about that then developers can opt out of it and keep writing Objective-C that's fine but that way it's not a one-way door and that way we're not walking into a trap if we make a mistake and it provided a relief valve that allowed it to happen.” --- ### [13:21](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=801s) 对比 Python 2 到 3：Swift 混编迁移的降维打击 ThePrimeagen 对此表示强烈好奇，因为在软件工程界，破坏向后兼容性向来是开发者最痛恨的雷区；即使到了今天，社区依然对当年 Python 2 升级到 Python 3 带来的十年阵痛怨声载道。他追问 Chris 究竟是如何说服人们接受“我们会改坏你的代码”（例如移除 `++` 和 `--` 运算符）这一决策的。 Chris 指出，Swift 从 2014 年发布至今刚好走过 10 年，而 Python 2 到 3 仅仅是过渡期就耗费了大约 15 年。苹果不仅成功实施了破坏性演进，甚至在比 Python 迁移更短的时间内，将整个庞大的 Objective-C 开发者社区彻底平移到了一个全新的语言平台上。其背后的本质差异在于**渐进式混编互操作（Interoperability）**： - **Python 2 到 3 的痛苦全量迁移**：整个程序必须一次性完全重写，所有的依赖包和三方库必须全部同步升级；一旦链条中存在一个无法迁移的小依赖，整个项目就会被牢牢卡死在原地。 - **Swift 与 Objective-C 的无缝混编**：两门语言在底层实现了极度艰难但至关重要的互操作。即使在现代 Swift 应用甚至苹果自身的代码库中，至今依然存在大量 C、C++ 和 Objective-C 代码。开发者坐拥上百万行老旧 Objective-C 代码时，完全可以仅将其中一个类迁移到 Swift，或者仅用 Swift 开发一个全新的业务模块。这种顺应人性、让工程师“把精力投在酷炫新业务而非翻修旧代码”的设计，也是他如今在 Mojo 项目中所坚决贯彻的核心哲学。 ```mermaid flowchart TD accTitle: Python 2 到 3 与 Swift 迁移模式对比 accDescr: 对比了 Python 的单体全量升级失败风险，与 Swift 支持逐个类混编平滑迁移的优势。 subgraph PythonMigration["Python 2 -> 3 模式（单体全量）"] P1["应用代码"] --- P2["核心三方库"] P2 --- P3["底层小依赖"] P3 -->|"任意节点不兼容"| P4["全盘卡死在 Python 2"] end subgraph SwiftMigration["Objective-C -> Swift 模式（渐进混编）"] S1["新业务模块（Swift）"] <-->|"ABI / 运行时底层互操作"| S2["百万行原有老旧代码（Obj-C / C++）"] S2 -->|"按需单类逐个替换"| S3["平滑无痛现代化升级"] end ``` - Chris Lattner 对比两次历史性迁移的根本技术差异：“In the case of Python 2 to 3 the entire Python program had to move all at once and so all your packages all your dependencies everything and so if you have one um one little thing that you depend on that can't move or is incompatible then you're stuck right in the case of Objective-C to Swift there's still a lot of Objective-C and C and C++ and all this other stuff in a modern Swift app... and so that ability to integrate and migrate and interoperate is so key and that was let me tell you an extremely difficult technical problem but that really changed the nature of adoption.” --- ### [16:03](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=963s) 苹果 2010 权责文化：Bertrand Serlet 与 Craig Federighi 的接力 针对 TJ DeVries 提出的“在庞大臃肿的企业组织中如何推动如此巨幅的底层文化转型”这一疑问，Chris 强调自己所谈论的是 2010 年左右的“老苹果”，与今天的苹果有着截然不同的运作面貌。 当时苹果的一个核心优势在于“清晰的所有权”（Clear Ownership）机制。当时的软件工程总监 Bertrand Serlet 是一位打造了 Mac OS X 绝大部分基础体系的传奇人物。他本身是一个不折不扣的 Objective-C 极客，但一直在积极寻求技术革新，曾大力推动在 Objective-C 中加入垃圾回收机制等现代化尝试；由于 Chris 深度参与了这些编译器与语言的探索，两人建立了极具信任的合作关系。随后 Bertrand 退休，接棒的 Craig Federighi 同样是一位极具战略眼光的高管；凭借深厚的 Java 和企业级平台背景，Craig 敏锐地洞察到生产力工具的重要性，并对更高效的现代化编程语言持极其开放的态度。 Chris 评价苹果高层的一大优势在于：顶层管理者非常聪明、具有极高的战略格局，并且对自家技术平台的长远命脉有深刻认知。真正的阻力往往并非来自最顶层的拍板者，而是中间层那些掌控 AppKit 框架、写了二十年 Objective-C 的跨职能老将——他们虽不直接拥有语言的技术管辖权，但在团队内部声望极高。说服这部分利益相关者，成了 Swift 能否正式面世最复杂的“组织政治学”试炼。 - Chris Lattner 点评高层决策机制与技术负责人的支持：“And so for them uh and this is again the thing I love about Apple is that the at the highest levels you have very smart very strategic leaders who are um really keyed into what matters for their technology platform um and so the challenge was I mean the there are many challenging conversations at that level for sure but but the bigger challenge is getting alignment and now you get these the cross functional people that were leading AppKit or something and they'd been writing Objective-C for 20 years and you know stuff like that and and they they had strong opinions but they didn't own it but they're important and respected and so that was much more like the politicking and that's where...” ### [18:50](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=1130s) 苹果的保密文化与决策权：Swift 面世内幕 Chris Lattner 回顾在苹果推动复杂项目时的沟通方式，他强调并没有什么捷径或魔法：“就是坚持不懈、保持理性、做好防守，认真倾听并做出反馈，同时撰写详实的文档，而不是仅仅依靠走廊上的随口闲聊。”撰写文档的目的是把对方的顾虑系统性地梳理清楚，使沟通具备可扩展性。然而，苹果最独特的一点在于其严苛的保密机制。Chris Lattner 透露，2014 年 Swift 正式发布时，苹果拥有成千上万名软件工程师，但全公司上下仅有大约 250 人提前知晓 Swift 的存在。当 Swift 在 WWDC 舞台上压轴亮相时，不仅台下的全球应用开发者目瞪口呆，“苹果内部大约 90% 的软件工程师同样被彻底震惊了”。ThePrimeagen 听后不禁感叹，在同一个发布会上既让全世界开发者狂喜，又给自家 90% 的员工扔下一颗深水炸弹，这种做法简直不可思议。 不过，从组织决策的角度反向审视，这种保密模式有其极为强大的战术优势。Chris Lattner 指出：“如果厨房里的厨师更少，做决策会容易得多。”在一个全然开放的企业文化中，要向成千上万名工程师解释和妥协，往往会导致寸步难行；而苹果的模式允许只召集那些具备理性思考能力的高层核心利益相关方，以及关键跨职能依赖项的技术骨干，从而推动激进而非渐进式的颠覆性变革。正如苹果当年在第一代 iPhone 研发时将整个软件团队完全隔离封存一样，团队得以全心创新，免受外界几百万个“为什么不这样”、“为什么不那样”的繁琐质询。ThePrimeagen 对此深有共鸣，提到自己在同等体量大厂工作时推行的“知情船长”（Informed Captain）制度：尽管前期充分收集各方意见，但最终由一人一锤定音并承担全部责任，“我现在是船长，我说了算”，这种方式能极大斩断扯皮、推进落地。 - 2014 年 Swift 发布时，苹果全公司数以万计的工程师中仅有约 250 人知晓该项目。 - 苹果内部约 90% 的软件工程师与 WWDC 现场观众在同一时刻得知 Swift 的诞生。 - 极少数关键利益相关方的封闭决策模式，是苹果能够推出类似 iPhone、Swift 这种非连续性颠覆创新产品的核心制度支撑。 --- ### [21:16](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=1276s) 复杂性的渐进式暴露：从 Java 的反例到 Swift 的设计失控 ThePrimeagen 提起 Chris Lattner 过去在播客中谈及的一个核心架构哲学——“复杂性的渐进式暴露”（Progressive Disclosure of Complexity），并询问这在现代语言中如何落地，以及哪款语言在这一点上做得最差。Chris 打趣道，最容易躺枪的反例非 Java 莫属：一个初学者仅仅为了写出打印字符串的 Hello World，就不得不硬吞一整套包括 `class Foo`、`public static void main(String[] args)`、`System.out.println`、方括号和包结构在内的全套概念。初学者连基本语法还没掌握，就被迫理解什么是类、什么是方法签名、什么是数组，这就是渐进式暴露机制的彻底崩溃。 ```mermaid flowchart TD accTitle: 复杂性渐进式暴露原理对比 accDescr: 对比错误设计直接将全部复杂语法压给初学者，与正确设计自顶向下平滑过渡的差异。 subgraph Bad["失控/反例设计 (如 Java / 后期 Swift)"] B1["初学者上手 Hello World"] --> B2["硬性塞入复杂概念: 类/访问修饰符/静态类型/样板语法"] B2 --> B3["陡峭的学习曲线 & 沉重的心智负担"] end subgraph Good["渐进式暴露 (理想范式)"] G1["简洁入门: 纯函数/基础脚本调用"] --> G2["平滑进阶: 按需使用高级特性"] G2 --> G3["硬核领域: 生命周期管理/高级元编程"] end ``` Chris 解释，“复杂性的渐进式暴露”原本是 UI/UX 设计领域的原则：语言应当提供极为强大甚至底层的特性，但不应该把它们生硬地砸在新手脸上。理想状态是“上手极简，深入后极其强大”。做好这一点的最大益处在于，不仅造福新手，也让老手受益——在处理日常逻辑时无需在脑海中加载一整座复杂的概念大山。然而，Chris 坦言 Swift 在后期的演进中在这一理念上“遭遇了惨痛的失败”，并留下了极其沉重的教训： > “在我看来，Swift 后来彻底失败了，留下了惨痛的教训。Swift 演变成了一大袋极其庞大、超乎想象的特殊情况、特殊语法和特殊机制。” —— Chris Lattner 造成这一局面的主要原因包括： - **闪电般的市场契合度（PMF）与技术债务**：Swift 诞生后，迫切渴望摆脱 Objective-C 的开发者极速涌入，用户群暴增。而仓促构建的语言内部堆积了大量技术债务，团队为了赶工应接不暇。 - **打补丁式的特例堆砌**：团队（包括 Chris 当年在任时期及离职之后）没有腾出手重构底层核心，反而不断添加语言特例。例如 SwiftUI 引入的“结果构建器”（Result Builders），其本质是一种在极端时间压力下赶出来的特化元编程机制，初衷仅仅是“为了在演讲幻灯片（Keynote Slide）上省略代码里的逗号，让 DSL 代码看起来更顺眼”。 - **代价高昂的后果**：这些为了特定特性而设立的局部补丁与语法糖，直接拖垮了 Swift 编译器的编译性能（Compile Times），并导致语言规范变得越来越沉重复杂。 --- ### [24:57](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=1497s) Mojo 的吸取与重构：统一底层抽象，干掉特例语法 吸取了 Swift 与 Rust 这一代语言的教训后，Chris Lattner 将全新理念注入到了 Mojo 中。Mojo 采取了截然相反的演进路线：从第一天起就开源透明构建，并明确向社区宣告“当前版本并不稳定，团队优先把核心底层体系打磨彻底”。面对社区层出不穷的诉求（例如追问 Mojo 为何至今没有类 Class），Chris 表示这绝不是技术难题：“我们完全懂得怎么做 Class，做 Class 根本不是什么难事。”团队当前的策略是克制冲动、划清界限，先专注把函数式及底层核心子集做到极致。 Mojo 继承自 Python 语言家族，吸取了 Python 将几乎所有操作都统一规约为“函数调用”的设计美感。Mojo 将诸如生命周期系统（Lifetimes）、所有权（Ownership）、异步机制（Async）等现代系统级语言的底层机制，原生统一凝练到函数抽象层面上。只要把底层的函数调用模型与核心抽象夯实，上层能力的组合扩展就能变得极其高效、自然。与 Swift 充斥着属性包装器（Property Wrappers）等一堆特化语法糖不同，Mojo 拥有更加系统且强大的编译时元编程基础设施（Metaprogramming），能够用一套通用的底层子系统吸收并消解掉原本需要几十个特例语法才能解决的问题，从而确保语言本身保持极其纯粹与简单。 --- ### [27:14](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=1634s) 评价 Go 语言的极简主义与泛型系统 ThePrimeagen 随后将话题引向 Go 语言，提问 Go 展现出来的这种近乎教条主义的极简主义，究竟是真正的简单，还是只是一种表面简单的假象——即语言本身虽然极度精简，却把大量重复复杂的负担全部抛给了实际编写代码的开发者。 Chris Lattner 坦言自己对 Go 怀有极高的敬意，尽管自己在 Go 方面的实践经验不及 C++、Swift、Rust 或 Python 那么深厚。他指出 Go 早期的一个重大经验教训是最初将自己定位为“系统级编程语言”，经过相当长一段时间的探索，团队才明确自身真正的阵地是“云原生与平台语言”（Cloud Platform Language）。一旦找准了这个定位，Go 在垃圾回收机制（GC）等方面的架构取舍便完全说得通了。谈及极简与复杂性时，Chris 特别提到自己曾被 Go 团队深深惊艳的一点：Go 团队后来居然成功将泛型系统（Generics）平滑引入了语言，并且完成度极高。相比于 Java 社区早期在没有泛型的情况下后续硬生生打补丁导致历史包袱沉重的教训，Go 能在保持自身极简主线下高质量地补全泛型系统，令人刮目相看。 ### [28:28](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=1708s) 从 Go 语言泛型演进中学到的审慎设计 在讨论语言复杂度的收敛与引入时，Chris Lattner 提到了 Go 社区在泛型设计上的长远克制。Go 团队长年划清界限，明确表态“我们先不引入泛型，看看没有泛型的生态如何演化，积累足够多的真实工程经验”，而不是盲目追求“赶紧把第一版泛型模型推上线”。他们经过极其审慎的推敲，用 Lattner 的话来说就是“测了 200 次才切下一刀”（measure 200 times and cut once），最终落地的泛型方案质量极高。 Lattner 坦言，这正是他在打造 Mojo 时所汲取的核心教训：不要因为外界所有人都在指手画脚就盲目随大流。在做 Mojo 的过程中，他每天都面临海量指责和建议，例如“Mojo 必须这样做”、“某某方式才是唯一解”或是“X 的绝对真理就是 Y”。Lattner 直言：“根本没有什么绝对真理，只有权衡取舍（there's no universal truth, there's only trade-off）。”Primeagen 听后打趣道自己也有一些建议，不过可以留到稍后再提。 ```mermaid flowchart LR accTitle: Language Feature Adoption Trade-offs accDescr: 对比冲动引入特性的方式与Go语言审慎测量200次的权衡取舍设计路径 subgraph Impulsive["冲动演进模式"] A["社区呼声与压力"] --> B["匆忙推出初版特性"] B --> C["设计瑕疵与历史包袱"] end subgraph Deliberate["Go / Mojo 演进哲学"] D["划清界限: 暂不引入"] --> E["长期观察与积累经验"] E --> F["审慎测量200次再落地"] F --> G["经受考验的优秀架构"] end ``` --- ### [29:16](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=1756s) 函数式编程为何未能真正流行？ TJ DeVries 将话题转向复杂性与用户群体的反差：既然 Lattner 打造的项目真正拥有数以百万计的活跃用户，那么一个深层疑问是：为什么函数式编程（Functional Programming, FP）始终无法成为主流？TJ 自称深爱 OCaml，许多观众也催促他询问 Lattner 对 OCaml 的看法——为什么 OCaml 不能像 JavaScript 或 Go 那样人尽皆知？ Lattner 回应称自己也非常喜欢 OCaml，早在很多年前就曾用 OCaml 写过一个带有严格尾递归（properly tail-recursive）的 Scheme 解析器。他直言“OCaml 实际上是我最喜欢的 ML 系列函数式语言”。TJ 立即开玩笑说要把“OCaml 是 Chris Lattner 最爱”这句话剪成切片印在 T 恤上。Lattner 随后补充，他同样是 Haskell 的狂热拥趸，但欣赏两者的原因截然不同：他喜欢 OCaml 的严谨（strict），以及比 Haskell 生态更轻巧简明的体系。 然而，OCaml 在现代硬件体系下面临着不可回避的现实困境： - **多线程支持滞后**：尽管 Jane Street 等团队多年来持续推动，OCaml 在多线程并行计算上的进展依旧缓慢。 - **大量装箱与指针间接寻址**：OCaml 列表等典型结构全部基于装箱（boxed）和多层指针，与现代计算机体系结构严重脱节。 - **现代硬件缓存架构的颠覆**：三十年前算法课上所讲的“链表在中间插入极快、数组在中间插入极慢”在今天的大规模实践中往往是错误的认知。现代计算机拥有多级高速缓存（L1/L2/L3 Cache），数组在内存中是连续排列的，而链表节点散落各处。遍历一个链表的实际开销，往往比遍历连续内存数组慢上 100 倍。 Lattner 指出，虽然 OCaml 和 Lisp 代表了上一代计算模型的辉煌，但现代计算机架构的变迁倒逼程序员必须以适配硬件局部性的方式编写代码。与此同时，函数式编程中真正优秀的设计思想——例如模式匹配（Pattern Matching）——过去被长期埋没在纯函数式圈子里，直到被 Swift、Rust 等现代语言发掘并带入大众视野。 --- ### [32:06](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=1926s) 纯函数式编程的核心硬伤与不可变状态神话 Primeagen 进一步追问核心痛点：为什么函数式编程作为一种思想概念本身，也难以被主流工程界普遍接纳？很多写函数式的人几乎立刻像皈依某种宗教一样穿上扎染 T 恤四处布道，为何大众还是不买账？ Lattner 给出了一个毫无保留的尖锐回答：“因为严格定义的函数式编程是愚蠢的，它在现实中根本说不通（functional programming strictly defined is dumb, like it doesn't actually make sense）。”面对全场爆发的大笑，他解释了这句夸张表达背后的工程本质： ```mermaid flowchart TD accTitle: Pure FP vs Real Hardware State Mutation accDescr: 纯函数式编程的全量拷贝机制与物理硬件可变内存之间的根本冲突 subgraph FP["纯函数式哲学 (Pure FP)"] FP1["需要改变一处状态"] FP2["重新分配并全量复制数据结构"] FP3["禁止就地可变 (In-place Mutation)"] FP1 --> FP2 --> FP3 end subgraph HW["物理计算机体系 (Modern Hardware)"] HW1["本质是一大袋可变状态 (Bags of Mutable State)"] HW2["依赖多级缓存与内存连续性"] HW3["频繁深拷贝导致极度低效"] HW1 --> HW2 --> HW3 end FP3 -.->|"理念与物理实现严重背道而驰"| HW3 ``` - **物理机器本质上是“一大袋可变状态”**：整个计算体系的底层就是管理可变内存。而纯函数式编程的教条是：如果要更新树结构或集合中的某个数据，就必须把整个数据结构重新分配并完整拷贝一份，在新副本中带上变动，彻底禁止就地可变（in-place mutation）。 - **大规模系统中的性能崩溃**：全量深拷贝的内存与吞吐代价极其高昂。在小型学术场景下或许尚可接受，但在现代大规模、高吞吐的工业级应用中完全无法扩展。 - **阵营割裂与原教旨争论**：关于“究竟什么是函数式”，业界自身充满了宗派主义。Scala 开发者自认是函数式程序员，但他们允许可变性；Haskell 程序员又会指责 OCaml 不算纯粹的函数式，因为 OCaml 是即时求值的（strict evaluation），而且原生支持可变字段（mutable fields）可进行就地修改。 Lattner 强调，他攻击的正是“为了修改一个局部数据而强行拷贝整个数据结构”的原教旨做法，这在现代大规模系统开发中行不通。 --- ### [35:12](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=2112s) 值语义（Value Semantics）的降维打击与所有权模型 为了解决纯函数式的性能短板，现代语言演化出了一条更优路径。TJ 提议深入探讨“值语义（Value Semantics）”的优越性，以及它在 Swift、Rust、Mojo 和近期 OCaml 的“Oxidizing OCaml”项目中的全面开花。 Lattner 解释了为什么值语义在理论与工程上都严格优于传统纯函数式： 1. **鱼与熊掌兼得**：值语义既能提供纯函数式带来的“行为隔离”与“逻辑组合能力”（开发者无需担心外部别名导致数据被暗中篡改），又能从容进行底层的**就地修改（in-place mutation）**。 2. **消灭无谓复杂度**：在纯函数系统中，为了修改包含 100 个元素的数组中的一项，程序员必须拷贝全部 100 个元素或指针；为了绕开性能灾难，工程师被迫设计出极其繁杂的不可变数据结构（例如前缀树 Trie、B 树等替代方案）。而值语义系统在确保当前操作拥有唯一所有权时，可以直接就地覆盖内存，性能既高，API 对开发者也更加直观友好。 3. **两种实现流派**： - **动态机制结合高级编译器优化（Swift 流派）**：Swift 偏向动态运行时配合写时复制（COW）及编译期优化，这种模式在苹果生态支撑了数以百万计的普通开发者，证明了其强大的工程扩展性。 - **静态严格所有权系统（Rust / Mojo 流派）**：对于不希望承担任何动态运行时开销、排斥隐式动态机制的系统级开发场景，语言可以通过显式的类型系统注解与借用检查（Borrow Checker），在编译期确立唯一所有权（Unique Ownership），直接实现零成本的就地修改。 “值语义在能力上严格强于那种形式的函数式编程，因为你既得到了函数式赋予的行为隔离与逻辑组合，又获得了就地变异的能力。”Lattner 总结道，这正是现代系统编程语言跨越纯函数式教条、向现代硬件妥协并取得成功的关键转折点。 ### [38:05](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=2285s) Mojo 的设计哲学与 Python++ 愿景 Chris Lattner 阐述了 Mojo 的核心追求：构建一种结合动态语言与严格底层控制的混合体。对于只想写普通代码、不在意少量运行时开销的 Python 程序员，Mojo 提供了熟悉的动态体验；而当开发者需要榨干硬件性能时，可以主动添加严格的类型注解与约束，直接获得嵌入式系统级别的底层控制权，将所有抽象开销剥离干净。这种设计遵循了“渐进式暴露复杂性（Progressive Disclosure of Complexity）”的原则。绝大多数开发者编写的代码并不直接处于性能热点上，他们完全可以随性黑客、快速迭代；一旦需要极致吞吐或延迟，再逐步叠加类型系统。这类思路在以往的很多编程语言中出现过，但在 Python 生态中由于历史机制和类型标注的特殊设计，始终没有被很好地贯彻。 ```mermaid flowchart TD accTitle: Mojo 渐进式复杂性架构 accDescr: 展示从动态代码平滑过渡到底层高性能代码的路径 subgraph DX ["开发体验层 (DX Layer)"] PyCode["普通动态代码 (无额外负担/快速原型)"] OptIn["可选添加严格类型注解 (Type Annotations)"] end subgraph Perf ["性能控制层 (Performance Layer)"] ZeroCost["零开销抽象 (Zero-cost Abstractions)"] Hardware["直接掌控硬件 / 嵌入式 / GPU 控制权"] end PyCode --> OptIn OptIn --> ZeroCost ZeroCost --> Hardware ``` 当 TJ DeVries 询问 Mojo 作为一个意图成为 Python 超集的语言，该如何避免演变成类似“Python++”的庞然大物时，Chris Lattner 直截了当地颠覆了这个问题：“Well so I think it it's, let me flip it around: it is actually a strong goal for Mojo to become a Python++, that is the goal, right?”（让我反过来看这个问题：成为 Python++ 实际上正是 Mojo 的强烈目标，这正是我们的目标所在，对吧？）面对大家经常提出的疑问——既然 Python 是一门持续演进的活语言，Mojo 作为超集该如何与其保持同步，Chris 用 C 和 C++ 的历史发展做类比。在 C++ 诞生初期（以“C with Classes”为代表），它由一个完全不同的委员会和社区推动，标准推进速度如同冰川般缓慢，但两个社区的开发者深度重叠。不仅 C 的特性进入了 C++，C++ 的创造也反哺了 C，最典型的例子就是 C 语言中采纳的 `void` 关键字其实最初源于 C++。Mojo 的目标从来不是“杀死 Python”，而是要终结系统层由 C/C++/CUDA 割裂掌控、顶层用 Python 做胶水胶合的双语言困境，用统一的现代化语言自顶向下打通整个技术栈。 - Mojo 秉持“渐进式暴露复杂性”，既保留 Python 的随性开发体验，又允许通过严格注解实现零开销底层控制。 - Chris Lattner 明确表示 Mojo 的愿景正是成为真正的“Python++”，类似当年 C++ 扩展 C 的生态角色。 - C 语言中的 `void` 关键字实际上最初是由 C++ 发明并反向被 C 标准采纳的，印证了双语言生态能够相互滋养。 --- ### [41:35](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=2495s) 与 Python 生态的互操作与底层兼容性策略 TJ DeVries 进一步追问兼容性风险：C 语言数十年来几乎从不打破向后兼容性，但 Python 历史上经常做出不兼容的重大改动（例如 Python 3.10 到 3.12 之间的演进），Mojo 该如何应对不断变动的 Python 版本？Chris 笑着透露，Python 创始人 Guido van Rossum 曾就这个问题当面严肃提醒过他，Guido 经历了 Python 2 到 3 迁移的惨痛教训，对语言的长期可持续性与兼容性拥有最多的“战斗伤痕”。 针对这个问题，Chris 将 Mojo 的兼容性明确拆分为两个完全不同的维度： 首先是**现行代码的互操作性（Interoperability）**。如今在 Mojo 中可以直接导入任意 Python 第三方包并无缝运行，开发者完全无需手动编写 FFI、绑定代码（bindings）或包装层。这项功能背后的实现机制是：Mojo 直接集成并调用标准的 CPython 解释器，由它负责解析和运行导入的 Python 包。CPython 拥有极为庞大的社区生态，负责诸如移除全局解释器锁（No-GIL）等长期基础设施攻坚，Mojo 团队不打算也没必要去重复造这部分轮子，而是直接通过 CPython 长期稳定的公共 C API 与之通信。即便 Python 官方进行大幅演进（如 No-GIL 计划耗时数年），Mojo 也能通过稳定的 API 适配层轻松跟进。 ```mermaid flowchart LR accTitle: Mojo 导入 Python 包的运行链路 accDescr: 说明 Mojo 如何借助 CPython 解释器实现无 FFI 兼容 Python 包 subgraph MojoEnv ["Mojo 运行环境"] MojoApp["Mojo 代码"] ImportPy["import 任意 Python 包"] end subgraph CPythonInterp ["CPython 解释器环境"] StableAPI["CPython 稳定公共 API"] StdInterp["标准 CPython 解释器"] PyPackages["NumPy / PyTorch 等原生 Python 生态"] end MojoApp --> ImportPy ImportPy -->|"直接调用"| StableAPI StableAPI --> StdInterp StdInterp --> PyPackages ``` 其次是**将 Python 代码直接迁移为 Mojo 代码（Code Migration）**。当前的 Mojo 尚未成为完整的 Python 超集，核心特性尚有缺口：比如当时版本中还没有实现完整的 `class`（类）以及列表推导式（List Comprehensions），这使得开发者迁移时需要进行少量改写（例如将 class 转换成 Mojo 的 `struct`）。针对代码语法偏好，Chris 吐槽道：“One thing that I don't super love is the postfix if thing, you say it's like x if condition else y, like I don't honestly I don't love that, but guess what, that's what Python does and so that's what Mojo does, let's not debate it, that's the thing, right?”（有一点我并不十分喜欢，就是那种后缀 if 语法，比如写成 x if condition else y。老实说我不太喜欢这种形式，但你猜怎么着，Python 就是这么干的，所以 Mojo 也必须这么做，没必要去争论，事实就是如此，对吧？）他强调，只要 Python 已经确立了既有模式，无论个人喜好与否，Mojo 都会严格对齐以降低学习成本。 - Mojo 无需手写 FFI 绑定即可直接运行 Python 库，本质是通过调用标准 CPython 解释器的稳定公共 API 实现的。 - 社区在 CPython 上的深层改造（如移除 GIL 的多年战役），Mojo 能直接以极小代价自然享用其成果。 - 当前将 Python 代码搬运到 Mojo 需要极少的手工改动（如将 class 暂改为 struct），未来列表推导式等语法糖均会陆续补齐。 --- ### [45:53](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=2753s) 代码迁移工具与语言超集的现实边界 当讨论到 Mojo 最终走向语法完全兼容 Python 时的版本碎片问题（例如兼容 Python 3.8 到最新版本），Chris 搬出了当年开发 Swift 语言时的宝贵实践经验：依赖**自动化迁移工具（Migrator Tools）**。在 Swift 早期演进的数年间，语言自身每个大版本都在打破向后兼容性，苹果团队正是通过提供代码升级迁移工具，自动解析旧版 Swift 语法并升版，实现了约 90% 的自动化替换，平稳带领整个生态实现过渡。 在 Mojo 未来的设计中，如果为了保证语言的一致性和表现力而引入了新的关键字，迁移工具可以通过简单的机制自动处理冲突（例如在冲突名称前加下划线转义）。Chris 直言，从纯粹的学术定义来看，Mojo 未必会成为绝对严格的 Python 超集，但这在工业界从来不是硬伤：“We technically will not be a superset because we take a new keyword or something, but guess what: C++ is technically not a superset of C either, correct, it takes new keywords and so it's fine, like we as a community can manage that, it's not that big deal.”（我们在技术上严格来说可能不算超集，因为我们占用了新的关键字；但你猜怎么着，C++ 在技术上也从来不是 C 的严格超集，对吧？它引入了新关键字。所以这完全没问题，我们作为一个社区完全有能力处理好，这并不是什么大不了的事。）随后，访谈主持人们顺势将话题引向了 Chris 过往主导的那些长盛不衰、影响深远的基础架构级巨型项目。 - Swift 早期曾连续数年自我破坏兼容性，依靠官方代码迁移工具完成了 90% 的自动化无痛升级，这一经验将被借鉴到 Mojo 中。 - Mojo 引入新的关键字时，将通过版本标记与自动化工具（如关键词转义）协助开发者管理 Python 代码的直接导入。 - C++ 因为占用了新关键字因而在严格意义上并非 C 的纯子集，Mojo 采取相同务实的工业界演进路径。 ### [047:41] 从业余项目到团队扩张：如何跨越“项目更迭”与精力分配 主持人 ThePrimeagen 抛出一个许多开发者关心的问题：Chris Lattner 过去常常秉持“通过亲手构建来学习”的理念（例如好奇 C 编译器有多难写，便在无数个夜晚和周末写出一个原型）。面对如此庞大的已有成果，他是如何管理探索新技术与维护既有庞大项目之间的时间分配？又是如何在 LLVM、Swift 等巨型项目与下一个全新事物之间自如切换，而不被外界无休止的新需求彻底拖垮？ Chris Lattner 先是幽默地调侃了一句：“I thought you're gonna be nice to me and now you're pointing out that I have like an attention problem and I can't stay something for more than eight years.”（我本以为你会对我客气点，结果你却指出我有注意力障碍，在一个项目上呆不过八年），随后引来 ThePrimeagen “Attention is all you need” 的机智接梗。回归正题后，Chris 解释了自己的角色演进方式。以 Swift 为例，在最初的一年半时间里，它完全只是他夜晚与周末的个人业余项目。当时他在苹果的本职工作是管理一个 40 人规模的团队，负责庞杂的业务线——涵盖调试器（LLDB）团队、基于 Objective-C/C++ 的 Clang 编译器链，甚至还要为苹果的自研 GPU 搭建一整套 LLVM 代码生成器，以支持硬件的完全自研。 Chris 指出，一个技术构想经过催化、原型构建并得到验证后，就会组建起正式的工程团队。团队中的优秀工程师往往能在具体实现上做得比他更好；作为管理者或技术主管，他继续扮演一线编码员反而会成为瓶颈。此时，他的核心价值在于系统架构设计、问题排查指引和方向把控。当团队能够独立高效运转后，他便自然有了精力去探寻下一个有价值的技术切入点。无论是最初做 Clang 还是 Swift，他起初都没有“统治世界”的宏大野心，仅仅是趁着想法还在脑海中、无需开会沟通的高效阶段，快速原型迭代，享受纯粹构建的乐趣。等到概念清晰、易于解释且个人业余时间无法再承载时，再引入团队和技术负责人接管，自己则顺理成章地迈向下一个阶段。 ```mermaid flowchart TD accTitle: 项目生命周期与 Chris Lattner 的角色演进 accDescr: 展示从个人业余原型到团队接管、管理者脱身探索新项目的全过程。 subgraph Phase1["阶段一：个人探索（利用业余时间）"] A["萌生想法与技术好奇"] --> B["快速原型开发（无会议开销）"] B --> C["概念验证与可行性落地"] end subgraph Phase2["阶段二：团队接手与体系化"] C --> D["组建专业工程团队"] D --> E["Chris 转为架构指导与技术主管角色"] E --> F["团队全面接管日常工程落地"] end subgraph Phase3["阶段三：抽身与下一轮创新"] F --> G["技术栈成熟自运转"] G --> H["寻找下一个前沿领域"] H --> A end ``` --- ### [050:57] 从零构建的恐惧：资深工程师的思维困境与全新系统设计法 Chris 分享了多年来在 Google 等顶级团队观察到的一个反直觉现象：极具才华的工程师在面对“从零构建（from scratch）”时往往会陷入集体瘫痪。他在 Google 负责带领团队为 TensorFlow 构建全新高性能机器学习运行时，当时在内部穿透层层阻碍、达成“立项开发新运行时”的共识本身就是一场极其艰难的政治与组织拉锯战。然而，当好不容易扫清障碍、Chris 对团队喊出“空间已经给你们腾出来了，上吧”之后，整个团队却面面相觑，完全不知从何下手。 Chris 剖析道：“these amazing Engineers had only ever worked on a mature project. They only added a feature or fixed a bug or they jumped into a big code base... outside of college very few people have the opportunity to build something from scratch.”（这些卓越的工程师以往只在成熟项目上工作过，他们做过的仅仅是添加功能、修复 Bug，或是跳进一个现有的大型代码库……在大学毕业后，极少有人有机会真正从零开始构建一个东西）。在像 Google 这样的巨头公司，资深开发者的看家本领是将极为庞杂的现有系统装进脑子，然后寻找局部最优解去“爬山式”改进。一旦被抛到没有任何既有框架的虚空边缘，多数人会感到巨大的恐惧，要么动弹不得，要么机械地重复以前做过的旧系统。 面对一张白纸，Chris 的方法不是去照抄旧系统，而是展开地毯式的既有成果调研（Survey）。在设计 Swift 时，他不仅观察同时期 Graydon Hoare 开发的 Rust，还深入调研了现代与经典语言——如 OCaml、Haskell，以及早已被大众淡忘的 CLU。他还会从垂直领域的语言中吸取极其具体的闪光点，比如 Dart 语言针对字符串 Unicode 转义序列的设计非常漂亮，他便毫不犹豫地“拿来主义”引入 Swift。通过广泛吸收前人经验，在虚空中勾勒出一座清晰的“城堡图景”，明确终极目标，再一步步迭代落地。 - **大厂资深工程师的能力偏向**：擅长在极度复杂的既有系统内吸收局部状态、持续做梯度改进（Hill-climbing），但极度缺乏从零划定架构边界的实践经验。 - **空白期工程心理**：面对没有既有代码的全新领域，开发者容易走向两个极端——因缺乏着手点而陷入瘫痪（Paralyzed），或是直接把曾经做过的旧架构照搬一套。 - **全局调研法（Survey Method）**：在动笔写第一行编译器或运行时代码前，深度调研包括冷门/古老语言在内的优秀设计（如 Dart 的 Unicode 转义机制），先勾勒系统蓝图再做定向实现。 --- ### [054:29] 放弃的艺术与创立 Modular：破解 AI 时代底层设施的泥潭 针对 ThePrimeagen 提出的后续疑问——“许多工程师最大的弱点就是不知道何时该放弃（Quit），要么放弃太早，要么坚持太久，你是如何在连续熬夜一年半做 Swift 这样的长周期里判断该坚持还是该转向”，Chris 没有抽象讲大道理，而是以当下创立 Modular 的真实决断作为案例。 Chris 直言，当前的 AI 行业呈现出一种冰火两重天的状态：一方面充斥着令人烦躁的炒作（Buzz）与荒谬泡沫；但另一方面，其底层基础设施（Foundational Infrastructure）和系统的演进却具有极其深远的变革意义。当下运行 AI 任务的底层软件栈堪称“巨大的灾难（a gigantic freaking mess）”——从专有的 CUDA、训练集群里残留的 MPI 协议，到上层五花八门互不兼容的系统，各种技术生拼硬凑，历史上从未经过自顶向下的系统性推敲。 Chris 回顾了自己在 2021 年 ASPLOS 会议上发表的主题演讲，当时他明确提出“当下是编译器的黄金时代”：海量异构硬件正在爆发，软硬件生态亟需一套大一统的底层理论，既能让软件工程师无需每次在硬件换代时被迫重写所有应用，也能让硬件创新者摆脱“每出一款新芯片就必须从头自造一套完整软件栈”的沉重枷锁。正是基于这种对底层技术痛点的深刻认知，他坚信必须打破现有的修修补补，从根基上重塑技术底座，而这正是催生 Modular 以及 Mojo 语言的核心驱动力。 > “the software developers to be able to build on a common platform so that you can then scale across all the different kinds of Hardware because most of us all software Engineers don't want to rewrite our entire app every time the thing changes right the the hardware changes right... and also by the way the hardware people don't want to reinvent an entire software stack every time they want to come out with a new chip basic observation” —— Chris Lattner ### [56:55](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=3415s) 屡遭质疑的创新之路与 Modular 的核心假设 Chris Lattner 回顾了自己职业生涯中屡见不鲜的被看衰经历。刚从学校毕业加入苹果去研发 LLVM 时，入职第一个月，GCC 团队的一位资深负责人就走到他面前直言：LLVM 不过是个学院派的研究项目，数百人已经在 GCC 上耕耘了数十年，他注定会失败，不如直接去做 GCC。后来着手开发 Swift 时，外界又搬出一套更具被动攻击性的说辞，声称新语言永远不可能成功、根本没人会采纳、构建语言成本太高，断言他必然折戟。Chris 坦言，自己被判定“注定失败”的次数实在太多，早已经习以为常，虽然 Twitter（X）把这些质疑放得更大、更频繁，但他并不在意。 创办 Modular 时，团队确立的目标不仅是为 CPU、GPU 以及各类加速器等极其重要的下一代异构计算构建统一平台，更是要在硬件厂商自家的芯片上击败他们自己的最强性能基准（State-of-the-Art）。面对“如何比 Rust 更快、如何战胜深耕自家芯片 20 多年的 Intel 顶尖工程师”的质疑，Modular 团队立足于一个科学假设：人类对特定问题的手工优化是无法横向扩展的，而现代编译器的通用性优化可以做到这一点。Chris 早期主导构建的新一代编译器框架 MLIR（可视为 LLVM 的继任者）虽然技术精湛且理念深远，但在当时几乎无人理解其工作机制，而它恰恰蕴含了解决现代异构硬件瓶颈所需的新算法与代码生成技术。 ```mermaid flowchart TD accTitle: Modular 成立背景与设计假设 accDescr: 展示从历史质疑到 Modular 技术假设的演进路线 subgraph Skepticism["历史质疑与应对"] A["LLVM 早期: 'GCC 做了数十年，你注定失败'"] B["Swift 早期: '新语言无法推行且成本极高'"] C["Chris 心态: 适应质疑，依靠技术验证说话"] A --> C B --> C end subgraph ModularThesis["Modular 核心技术假设"] D["硬件现状: 矩阵乘单元、NUMA、多 Socket 异构架构"] E["传统局限: 20年前软件架构，依靠专家手写汇编特例"] F["全新路径: 全新编译器 (MLIR) + 异步运行时 + 自动算子融合"] G["验证结论: 编译器通用优化性能超越 Intel MKL"] D --> F E --> F F --> G end C --> ModularThesis ``` - “像 Swift 或 Rust 这些语言甚至根本没有尝试去解决这个问题，它们连 SIMD 都勉强才支持。”（“...which by the way none of Swift or Rust or any of these languages even attempt to solve, they can barely do SIMD...” —— Chris Lattner） - “我们证明了编译器的通用性能够击败人类针对特定单一方案打补丁式的优化，因为人类无法横向扩展，而编译器可以规模化扩展。”（“...and that what we proved is that the generality of a compiler beats humans special casing individual point solutions because humans can't scale, the compiler can scale.” —— Chris Lattner） ### [58:33](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=3513s) 击败 Intel 汇编基准与 Mojo 的诞生逻辑 Chris 深入阐释了现代计算硬件面临的严峻挑战：无论是 CPU 还是专用加速器，硬件层面都集成了硬件矩阵乘法单元等新型计算模块；在服务器端，多核与多路 CPU 带来了复杂的非统一内存访问（NUMA）架构，内存访问延迟因位置不同而产生巨大差异。然而，市面上绝大多数通用底层软件都是为 20 年前的芯片架构编写的。为了验证自己的技术路线，Modular 团队从底层构建了一套极具颠覆性的编译器和基础构架：包括全新的底层高性能异步运行时、全新的线程池实现、全新的 SIMD 编程范式，以及彻底消除内存往返流量的自动算子融合（Automatic Kernel Fusion）技术。 团队用这一套高级编译器方案在 Intel 芯片上生成矩阵乘法代码，直接对标并成功超越了 Intel 由数千名天才工程师手写底层汇编调优的 MKL（Math Kernel Library）最高性能。在 2022 年底验证了这一假设后，团队面临着新的难题：整套深奥的编译器框架极其复杂，全世界能看懂底层运作的不过寥寥数人。他们必须找到一种前端语法把这套底层的算力表达出来，于是团队开始四处物色现存语法，最终选定 Python 作为语法外壳。Mojo 的诞生绝非“为了好玩去发明一门语言”，而是在面对下一代硬件架构并构建出强大的编译器内部结构后，推导求解出的一套工程必然方案。 - 现代语言的盲区：Rust 和 Swift 等现代语言在底层设计上无法高效调度现代硬件的专用矩阵计算单元，亦无法良好应对多 Socket 服务器下的 NUMA 架构。 - Mojo 的本质演进：并非从零拍脑袋设计语言，而是为已验证能够击败硬件厂商汇编性能的编译器后端寻找并匹配了 Python 语法外壳。 ### [01:01:41](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=3701s) 彻底重写的全栈编译器与对 LLVM 的超越 TJ DeVries 提出他的理解，认为 Mojo 本质上就像是 MLIR 的一套直接前端抽象。Chris 证实了这一说法，但他立刻指出了当前业界的巨大误区。虽然 MLIR 是解决桌面端（如 Apple Silicon）以及数据中心复杂加速器的正确抽象工具，但目前收录在 LLVM 伞状项目下的 MLIR 充斥着极其庞杂和繁复的学院派代码，而 Modular 几乎不使用官方那些现成的 MLIR 方言（Dialects）。外界常问“你们怎么可能比 Rust 等成熟语言更快”，误以为只要都是零成本抽象，所有语言底层就别无二致。Chris 强调，这种“底层一样”的前提是大家共享相同的代码生成后端；而 Modular 是从零重建了包含全部前端和中端的完整编译器技术栈。 ThePrimeagen 感叹道，听完这番解释他终于信服 Mojo 确实能比 Rust 更快，因为这相当于彻底更换了底层引擎的赛车，而非仅仅在旧车壳上刷漆。Chris 坦诚表示，LLVM 是一项诞生了 20 多年的优秀技术，他为 LLVM 对世界的贡献感到骄傲，但它绝非完美无缺，自己比任何人都更清楚 LLVM 现存的技术缺陷。在 Modular 团队参加的 LLVM 开发者大会上，他们就曾公开分享过 Mojo 的架构哲学：“我们用的是 LLVM 优秀的那些部分，而不是沿用整套旧的 LLVM 系统。” - “这确实是事实，如果你们都在使用相同的代码生成器，那大家确实都一样；但如果你做的是全新的东西，那一切就截然不同了。”（“...and it's like, well, that's true if you're all using the same code generator, but if you're doing something new, then it's not all the same.” —— Chris Lattner） - “我太清楚这些问题了，比任何人都清楚。事实上，在去年秋天的 LLVM 开发者大会上，我们就 Mojo 做了一场演讲，我们解释说：我们使用的是 LLVM 好的那些部分，而不是整套 LLVM 体系。”（“I know the problems better than anybody. In fact, if you look at the LLVM Developer Meeting last fall, we gave a talk about Mojo and we explained it's like we use LLVM the good parts, not the LLVM system.” —— Chris Lattner） ### [01:04:09](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=3849s) 编程演进的借鉴：Zig 与 Mojo 的元编程 随着直播公开部分接近尾声，主持人 ThePrimeagen 表达了由衷的感谢，提到 Chris Lattner 过去二十年打造的底层基础设施启发了整整一代程序员，没有 LLVM 就根本不可能有当今的现代编程语言生态，包括他个人非常推崇的 Zig 语言目前也是重度依赖 LLVM 构建。 Chris 随即透露，他自己同样非常喜爱 Zig，并且 Mojo 在设计上直接吸收借鉴了 Zig 的许多优秀理念，其中就包括 Mojo 整个编译期执行的元编程系统（Comptime Metaprogramming）。他感慨道，外界很多人往往不习惯技术其实一直都在不断进化这一事实，优秀的开发者必须始终向新的设计学习并向前迭代。随后 ThePrimeagen 宣布结束公开推流，带领 Twitch 高层级订阅者转场至私人 Discord 语音频道，以便在 Chris 离场的最后十余分钟内继续解答更加极客和深入的技术细节提问。 - “很多人就是不习惯‘技术进步一直都在发生’这个事实，所以你必须从中不断学习吸收。”（“This is again, people are not used to the fact that progress is being made all the time, and so you have to learn from it.” —— Chris Lattner） ## Notable quotes > [56:55](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=3415s) 我们证明了编译器的通用性能够击败人类针对特定单一方案打补丁式的优化，因为人类无法横向扩展，而编译器可以规模化扩展。 — Chris Lattner > [21:16](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=1276s) 在我看来，Swift 后来彻底失败了，留下了惨痛的教训。Swift 演变成了一大袋极其庞大、超乎想象的特殊情况、特殊语法和特殊机制。 — Chris Lattner > [06:58](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=418s) 如果你想要发布一门编程语言，这可不仅仅是写一个编译器那么简单。你必须配备一本书、实现 Xcode 深度集成、打造专属调试器、设计出真正美观易用的 API——要做好这一切，需要的是庞大得多的资源承诺。 — Chris Lattner > [02:37](https://www.youtube.com/watch?v=ovYbgbrQ-v8&t=157s) Rust 能够做尾递归消除并转成 for 循环这种骚操作，完全是因为 21 年前一个大学在读生突然想到了一个算法并将其实现进了 LLVM，这才有了今天 Rust 的这一特性。 — Chris Lattner ## Mentioned Chris Lattner, ThePrimeagen, TJ DeVries, LLVM, Clang, Swift, Mojo, Modular, MLIR, Vikram Adve, Bertrand Serlet, Craig Federighi, Guido van Rossum, Graydon Hoare, 伊利诺伊大学厄巴纳-香槟分校 (UIUC), 苹果 (Apple), Objective-C, Rust, Python, Go, OCaml, Haskell, Zig, C++, C语言, CUDA, Intel MKL, TensorFlow, SwiftUI, Xcode, LLDB ## Video description Recorded live on twitch, GET IN ### Guests Chris Lattner https://x.com/clattner_llvm?s=21&t=-sv4MdpmLrRuMIhARbLk-g https://www.modular.com TJ DeVries https://youtube.com/@teej_dv?si=AIrpF3SWJYZqlboU ### My Stream https://twitch.tv/ThePrimeagen ### Best Way To Support Me Become a backend engineer. Its my favorite site https://boot.dev/?promo=PRIMEYT This is also the best way to support me is to support yourself becoming a better backend engineer. MY MAIN YT CHANNEL: Has well edited engineering videos https://youtube.com/ThePrimeagen Discord https://discord.gg/ThePrimeagen Have something for me to read or react to?: https://www.reddit.com/r/ThePrimeagenReact/ Kinesis Advantage 360: https://bit.ly/Prime-Kinesis Get production ready SQLite with Turso: https://turso.tech/deeznuts [Source](https://www.youtube.com/watch?v=ovYbgbrQ-v8)

[56:55] Chris Lattner: 我们证明了编译器的通用性能够击败人类针对特定单一方案打补丁式的优化，因为人类无法横向扩展，而编译器可以规模化扩展。 [21:16] Chris Lattner: 在我看来，Swift 后来彻底失败了，留下了惨痛的教训。Swift 演变成了一大袋极其庞大、超乎想象的特殊情况、特殊语法和特殊机制。 [6:58] Chris Lattner: 如果你想要发布一门编程语言，这可不仅仅是写一个编译器那么简单。你必须配备一本书、实现 Xcode 深度集成、打造专属调试器、设计出真正美观易用的 API——要做好这一切，需要的是庞大得多的资源承诺。 [2:37] Chris Lattner: Rust 能够做尾递归消除并转成 for 循环这种骚操作，完全是因为 21 年前一个大学在读生突然想到了一个算法并将其实现进了 LLVM，这才有了今天 Rust 的这一特性。

[59:25] Chris Lattner: What we proved is that the generality of a compiler beats humans special casing individual point solutions because humans can't scale, the compiler can scale. [21:16] Chris Lattner: Swift has turned into a gigantic, super complicated bag of special cases, special syntax, special stuff, and it's all locally well-intentioned. [50:57] Chris Lattner: Outside of college very few people have the opportunity to build something from scratch.

[0:00] first off hey everybody Welcome this is [0:02] going to be what we were referring to as [0:03] the top shelf where we get some pretty [0:05] high uh impact guests to come on and [0:08] kind of talk about what they've done and [0:10] we're hoping to get some pretty unique [0:11] angles to what we're asking and what [0:13] we're doing and today we have on here [0:14] Chris lner you might be probably one of [0:16] the most influential Engineers I think [0:19] of our time uh the things that you've [0:22] written affect millions of people [0:24] directly and indirectly potentially most [0:27] people on earth I would say that clang [0:29] and llvm play a huge role in affecting [0:31] people's everyday lives whether they [0:32] realize it or not uh and also you've [0:35] written Swift and now you're working on [0:37] mojo as kind of like the big highlights [0:39] of everything you've done uh pretty [0:41] impressive you have a PhD which is [0:43] already more impressive than most people [0:44] in chat they can't even believe phds [0:46] actually exist so very impressive uh I [0:49] think chat's most surprised you have a [0:50] PhD and you're not like still writing [0:53] haskal I think that's what what chat [0:55] considers one of your crowning [0:56] achievements yeah I wasn't I mean I I I [1:00] I had a great time in graduate school I [1:02] was an actually great graduate student [1:04] writing the papers and being the [1:05] academic was not my thing but it was [1:07] really amazing to get paid to work on [1:08] the stuff that I want to build so okay [1:11] when you said you weren't good at being [1:12] an academic what how do you get a PhD [1:15] how do you want to subject yourself to [1:16] that many years of school but not being [1:18] good at it uh I didn't so I went to [1:21] Illinois um with the goal of getting in [1:24] and out in a year with a master's degree [1:26] and then uh my adviser vickram uh nerd [1:29] sniped me and and start working on this [1:31] lvm thing and that became really cool [1:35] and I was having fun and then I decided [1:36] not leave so it's it's all his [1:39] fault dang that's actually you know nerd [1:42] sniping is an extremely powerful [1:44] technique and I realize that you can [1:46] solve a lot of problems by getting [1:48] somebody else excited about what you're [1:50] doing yeah well so I mean I I think that [1:52] something that defines what I work on is [1:54] that I work on it both because I you [1:57] know intellectually care about achieving [1:59] a thing but also because I just fall in [2:00] love with the problem and I what get [2:02] really excited about it and it's the [2:03] enthusiasm that drives this not just the [2:06] rational this needs to be solved in this [2:08] way for whatever reason I also love the [2:10] process of discovery and so being able [2:12] to work through something and and really [2:14] understand it because you you build into [2:16] this uh the space really gives you a [2:18] Hands-On way to understand and build [2:20] things and I'm H very fortunate that [2:22] some of it was useful to other people [2:23] too and that's that that's pretty cool I [2:26] do like this little bit of history that [2:28] I didn't know that it was lvm is just [2:31] the world's longest and largest nerd [2:33] snipe that's ever happened like I really [2:35] like this little tidbit [2:37] now yeah well I mean it's it's super [2:39] funny right I mean you talking about [2:41] Russ when we did the uh Mojo's faster [2:44] than Russ blog post a lot of people are [2:46] saying like oh my God this is this can't [2:47] be true rust has pil calls and uh you [2:50] know it'll even turn pil recursive [2:53] functions into uh for Loops things like [2:56] this right and the thing that I think [2:58] I'm pretty sure that 99 % of people [3:00] don't know or certainly the people that [3:02] are commenting don't understand is that [3:03] Russ does tail recursive for Loop [3:05] elimination nonsense because a [3:08] university student literally 21 years [3:10] ago got an idea for an algorithm [3:13] Implement into lvm and now here you go [3:16] Russ can do this thing and so he can go [3:18] look at tail recurve elimination if you [3:20] go all the way back 21 years in history [3:22] you can see me acing away having fun [3:24] learning how this little algorithm works [3:25] and now it's it's a cool thing that rust [3:28] and Swift and Julia and playing and like [3:32] all this universe of languages can I all [3:34] just get for free which is pretty cool [3:36] so what you're trying to say is you are [3:38] one of the top contributors to rust and [3:40] its [3:41] performance actually that would be [3:42] really interesting I am still by far the [3:45] top contributor to LM um including all [3:47] of it sub projects I haven't done that [3:49] cross comparison with rust you can go [3:53] look at my GitHub profile on github.com [3:55] latner and so like I'm still writing [3:58] thumb code and doing some stuff but the [4:01] uh I haven't done that cross comparison [4:03] to rust or other communities that's very [4:05] interesting all right so uh we we are [4:06] going to kind of go back and forth on [4:08] some questions and we're gonna let TJ [4:09] kind of start start us off yeah so one [4:12] of the things that I'm kind of [4:13] interested in as someone who loves some [4:16] uh not as popular languages is when you [4:19] started working on Swift at Apple uh one [4:22] of the things you had said is that there [4:23] were still a lot of people who loved [4:25] Objective C so from sort of like [4:28] a almost like The Human Side of the [4:31] problem the structural side of the [4:33] problem what what were some of the [4:34] things that you did to deal with uh [4:36] hesitancy I mean obviously for Swift [4:39] it's even bigger than a lot of the kinds [4:41] of introducing ne new technologies [4:43] because yeah you know you had to write [4:45] an entirely new language but there was [4:47] lots of people at Apple who were like oh [4:50] I've been writing Objective C for I [4:52] don't know longer than I've been alive [4:54] wait why why do we need this new thing [4:56] right so like how did you tackle that [4:58] inside of Apple [5:00] yeah so so great question let me let me [5:01] just give you some factoids on that so I [5:03] started working on Swift in 2010 it was [5:06] the nights and weekends project uh 2014 [5:10] it launched publicly to the world and [5:12] then it got open source in 2016 right so [5:15] you're talking about just that six-year [5:17] time frame um by the time it launched [5:20] four years into its Journey um only [5:22] about 250 people knew about it at Apple [5:25] okay and this is because of Apple's [5:26] secrecy and like all the things that [5:29] apple both uh notorious for and also [5:31] wonderful at and so and so one of the [5:35] big questions I think you're getting at [5:36] is like how do you actually go [5:39] from like a crazy idea to something that [5:41] launches publicly to the world and now [5:43] millions of people use right and so um [5:46] so in the case of Swift it was literally [5:48] nights and weekends project that nobody [5:50] at Apple even knew about except for me [5:52] for a year and a half so that four years [5:55] a year and a half of it was just me [5:57] working on a thing to understand it to [5:59] explain I had a day job running several [6:01] really big teams and so it was a relief [6:03] Val after uh getting C++ to work and [6:06] clang and get the compiler to bootstrap [6:08] and build boost and like all these cs+ [6:10] is a very formidable language to [6:11] implement and so you can't come out of [6:12] that without some PTSD and so Swift was [6:15] kind of releas well um by the time it [6:18] got interesting and it was I was [6:19] starting to understand it because again [6:20] I have to build things to really [6:22] understand it then I said hey management [6:25] uh what do you think about this project [6:27] right and the plus one apple I built up [6:30] enough credibility for delivering things [6:32] that they didn't immediately say go away [6:35] kid like you're not GNA like this is [6:37] this is dumb they kind of said well [6:38] that's very interesting but we have [6:40] other higher priority things to do right [6:42] and so um and in time I was granted the [6:45] ability to like have some of the people [6:47] that were already working for me like be [6:49] told about it first but then also start [6:51] contributing to it and kind of gain [6:54] momentum about three years in remember [6:56] it launched after four years about three [6:58] years in there became this really big [7:00] decision point and the decision Point [7:02] became does Apple actually put [7:04] significant resources into it and to [7:05] launch a language it's not just about [7:07] having a compiler you need to have a [7:09] book you need to have xcode integration [7:11] you need to have a debugger you need to [7:13] have apis that actually look nice you [7:15] have to it's a much bigger commitment to [7:18] be able to do this and so about three [7:20] years in there was a major series of [7:22] executive [7:23] reviews and that became a whole range of [7:26] conversations around should we do this [7:28] should we not like what does this look [7:30] like Etc and the push back and I think [7:33] this is actually by the way Apple at its [7:35] best because apple is capable of making [7:38] extremely hard decisions um but it puts [7:42] those decisions through a rigorous [7:44] process to actually you know the burden [7:46] is high and so in this case like the the [7:48] problems I had to solve were things like [7:50] okay cool um you're going to launch this [7:53] new language what if it fragments our [7:55] developer community in half what if some [7:57] people like this other people like [7:59] objective and now we've now made our [8:01] entire Community more pregnant right big [8:04] question another question was okay well [8:07] if Objective C has problems why not just [8:09] fix Objective C that's a very classic [8:11] kind of argument among Industries is [8:13] always why not just fix what we already [8:15] have right and so and so what we did was [8:18] we said okay said yes let's make obcy [8:20] better and so what we ended up doing is [8:22] we added modules objectivec literals Arc [8:25] reference uh AO me memory management to [8:29] objective which it didn't have [8:30] hilariously um and all these things and [8:32] what and what they were doing is twofold [8:33] one is pulling Objective C forward and [8:36] making it more productive and better and [8:38] improving obcy in place but also pulling [8:40] towards Swift because we need to talk to [8:43] obcy API so we need modules or we need [8:45] to be able to have automatic memory [8:46] management and so we needed Objective C [8:48] to actually have something rigorous and [8:50] and things like this right um a big [8:53] challenge that I faced was I kept [8:55] getting these like push backs like from [8:56] various very senior software leaders and [9:00] they they would ask these like really [9:02] elusive questions like that that are not [9:05] possible to answer and there were [9:07] questions like well how do we know it's [9:08] going to be better or how do we know [9:10] that somebody won't like this thing or [9:11] there's this one feature or this one [9:13] syntax or whatever and why why don't [9:14] blah blah blah blah right or I I don't [9:17] like the way this feels or looks or [9:18] whatever right and one of the things I [9:20] realized and TJ I think you're getting [9:21] at this is that um effectively all the [9:24] software engineers at Apple at that time [9:26] had grown up and joined Apple because of [9:29] Objective C the senior software leaders [9:31] worked at next like 15 years ago and [9:35] they they were there because of [9:37] objective c and they would ask these [9:38] questions like well Objective C isn't a [9:40] problem like our entire developer [9:42] Community is objective c the iPhone is [9:45] successful because of objective c and [9:47] this amazing and it is in its own way [9:49] it's this amazing combination of [9:51] dynamism and objects combined with the [9:54] power and performance of c and so right [9:57] why why why are you going to fix this it [9:59] ain't Bren right and what I realized is [10:01] that all these people because they had [10:03] joined for objective c and that's what [10:05] they knew inside and out and that's how [10:06] they had built their careers many of [10:08] them were now in these senior leadership [10:10] positions they weren't wrri they were [10:11] not writing code anymore and so what [10:13] Swift represented was a reset of their [10:15] expertise back to zero and so I'm a kind [10:19] of a dense person people are maybe not [10:21] my strong point but um but once I [10:24] realized that suddenly it became like [10:27] don't go engineer brain on uh this is [10:30] the way this is why we not going to [10:32] require semic Colones or whatever right [10:33] instead go into reassuring like this is [10:36] why it's going to be okay this is why [10:38] everything will transfer over we'll keep [10:39] all the apis blah blah blah blah blah [10:40] we'll keep everybody you know the the [10:42] important thing is the design patterns [10:44] from the Frameworks and the apis and [10:46] like all those come over without change [10:47] and and I was able to find a way to [10:49] explain it a way that mapped into the [10:51] value system made it so that people um [10:55] even people much more senior than me [10:57] would be heroes in their Journey still [10:58] and be able to do that and that that's [11:00] one of the things that allowed it to get [11:02] through another really big thing that [11:04] that I think allowed Swift to get [11:06] launched was um people would always ask [11:10] uh very romly okay well you know so far [11:14] a team of like five people 10 people [11:15] have built this [11:17] language um maybe 200 people most of [11:20] whom work for me uh have seen it now uh [11:25] how do we know it's good how do we know [11:27] that we're not going to like you know [11:29] we're going to launch this thing and [11:30] it's going to be embarrassing or [11:32] whatever and what and what I told people [11:35] is and again spent a bunch of time going [11:37] around and you know I make this all [11:39] sound linear but of course this is very [11:40] messy and complicated and in in and out [11:43] and lots of different things um what I [11:46] told what I realized is that the problem [11:48] was the Apple when it launches things [11:50] they want to say app developers can be [11:51] able to use this and therefore you're [11:52] protected from [11:54] incompatibility and so the Breakthrough [11:56] was when I realized look let's just tell [11:58] people it won't be compatible like Swift [12:02] you can use it you can sub it to the App [12:03] Store we will break your code because we [12:07] have not gotten a lot of miles on this [12:08] thing our goal is to make this good not [12:11] just nail it down and once I once we got [12:14] through that then exact leadership was [12:15] like oh well okay well if we're clear [12:18] about that then developers can opt out [12:19] of it and keep ring objectiv see that's [12:21] fine but that way it's not a oneway door [12:24] and that way we're not walking into a [12:25] trap if we make a mistake and it [12:27] provided a relief valve that allow [12:29] happen and so a lot of Swift again as [12:31] you're saying like on the human side and [12:33] on the culture side on the this kind of [12:35] side it was these kinds of challenges [12:38] which really have nothing to do with [12:40] compilers or semicon or the technical [12:42] stuff which is also super interesting um [12:44] but uh but was a big part of getting [12:47] getting Swift to happen another big [12:49] piece was um being able to show how we [12:53] could go beyond Objective C and so one [12:55] of the big pieces was memory safety and [12:57] so you know an object C you can't remove [13:00] pointers and have it still be C or [13:02] objective c like that that was that was [13:04] a big thing just OBC thing was yeah just [13:07] subjective yeah uh but the but then the [13:09] other piece was like how can we build [13:11] value ad experiences into xcode and [13:13] things like this and so I don't have a [13:14] huge amount of love for xcode [13:16] practically but um but uh xcode is very [13:19] important to Apple and so that was a big [13:20] case of it I'm very curious about how [13:22] you sold people on the ability to say [13:24] that we're going to have a language in [13:26] which will break backwards compatibility [13:28] because I mean to the this day people [13:30] are still fighting about python right [13:32] like I mean I still hear people upset [13:35] about the two to three break and so I [13:37] can't like that just seems like much [13:39] harder of a cell to be like you know [13:41] what we're going to go out there and [13:43] we're going to break you like H how how [13:44] did you managed to convince anybody that [13:46] that was a uh a good [13:48] idea because the minus minus and plus [13:50] plus I believe was your kind of primary [13:52] example that you gave about breaking [13:54] Swift so um well let me let me give you [13:58] again just time frame [13:59] uh Swift is just 10 years old now from [14:02] its launch it's launched in 2014 I was I [14:06] think it's still 20124 I lose track [14:08] sometimes but the uh but python 2 to3 [14:10] took 15 years just for the [14:12] transition right if order magnitude [14:15] something like that right and so so so [14:18] not not only did we make a change in [14:20] Swift literally moved the entire [14:23] objective c community to completely [14:25] different [14:27] language in less time than python two to [14:29] three right so not not I mean maybe I'm [14:34] humble bragging a little bit here but [14:35] the um uh but how is that possible well [14:38] it's because it's a completely different [14:40] kind of transition so in the case of [14:42] python 2 to3 the entire Python program [14:45] had to move all at once and so all your [14:47] packages all your dependencies [14:48] everything and so if you have one um one [14:51] little thing that you depend on that [14:52] can't move or is incompatible then [14:55] you're stuck right in the case of [14:57] objective c to Swift there still a lot [14:59] of Objective C and C and C++ and all [15:02] this other stuff in a modern Swift app [15:05] like a lot of Apple's written a [15:08] tremendous amount of Swift code for sure [15:09] but they still have a lot of objective c [15:11] code in their stack and so that ability [15:13] to integrate and migrate and Inter [15:15] operate is so key and that was let me [15:17] tell you an extremely difficult [15:19] technical problem but that really [15:21] changed the nature of adoption and so [15:24] one of the things that allowed Swift to [15:25] get adopted very quickly is the app [15:27] developers could take their objective c [15:29] apps that they' written you know [15:31] sometimes a million lines of code and [15:33] then move one class over right and so [15:35] now you have that's cool that's really [15:37] cool yeah whole whole thing in Objective [15:39] C and I'm going to write some new [15:40] feature in Swift right and so this is [15:43] where I mean we take all these lessons [15:45] to Mojo and it's the same same ideas [15:47] right and so you make it so that you [15:48] don't have to be monolithically changing [15:51] everything all at once you actually work [15:53] the way the developers work which is [15:54] that they want to invest time into [15:56] things that are cool and shiny and new [15:58] and important for their business or [15:59] whatever um not the dusty deck code [16:01] that's fine I just want to ask one last [16:03] thing just sort of relating to those [16:05] sort of people sort of difficulties [16:08] there how did you set up like Apple's [16:10] huge first off so I mean obviously it's [16:12] difficult in one way to even have [16:14] conversations with people across your [16:16] team regardless right like getting 10 [16:18] people to agree on something is hard [16:20] enough let alone however many Engineers [16:22] work at Apple but how did you sort of [16:25] create I don't know the culture or or [16:27] how did Apple create the culture where [16:29] you could actually have a conversation [16:31] about getting Swift to go anywhere like [16:34] that's super surprising from from my [16:36] side just from seeing like oh how do you [16:37] even get people to have a conversation [16:39] about changing the way things were like [16:42] culturally at a at a tech place in such [16:44] a big way right it's not just like oh [16:45] we're going to switch libraries for [16:48] logging um well so so I think that it's [16:51] it's a combination of multiple different [16:52] things one is um well how this apple [16:56] there's very Apple like any place has [16:58] positives and negatives and when I talk [17:00] about Apple I'm talking about Apple 2010 [17:03] which is very different than Apple today [17:06] okay and I have been out out of Apple [17:08] for many years and so I can't speak to [17:09] Apple today I'm talking about kind of [17:11] old Apple when uh and so things are a [17:14] little bit different um but one of the [17:17] things that was really true is that [17:18] there was clear ownership and so the [17:21] head of software this guy named brron [17:23] surle amazing amazing human uh he built [17:27] a lot of Mac OS 10 he he led the team [17:30] through a lot of changes and did a lot [17:31] of the core technology within the stack [17:34] he happened to be an Objective C nerd [17:37] and he was pushing for things like [17:38] garbage collection and a bunch of other [17:39] things to try to modernize the language [17:41] um and so I got close to him because I [17:43] was helping drive and work on a lot of [17:45] these kinds of things um later he [17:47] decided to retire and move on and uh his [17:50] replacement Craig fedi also amazing [17:52] technical leader really understood this [17:54] stuff came into this and he had a bunch [17:56] of java experience and or gave platform [17:59] experience more broadly and um and so he [18:01] brought in A New Perspective and so this [18:04] idea of having more productive [18:06] programming languages wasn't just like a [18:08] complete [18:09] reject concept at the very top um and so [18:13] for them uh and this is again the thing [18:16] I love about Apple is that the at the [18:17] highest levels you have very smart very [18:19] strategic leaders who are um really [18:23] keyed into what matters for their [18:24] technology platform um and so the [18:27] challenge was I mean the [18:29] there are many challenging conversations [18:30] at that level for sure but but the [18:32] bigger challenge is getting contestant [18:33] in alignment and now you get these the [18:35] cross functional people that were [18:37] leading appkit or something and they'd [18:38] been writing Objective C for 20 years [18:40] and you know stuff like that and and [18:43] they they had strong opinions but they [18:44] didn't own it but they're important and [18:46] respected and so that was much more like [18:48] the Pol politicking and that's where [18:50] things were more complicated and there I [18:52] don't think there was any magic it was [18:53] more about yeah being P persistent about [18:56] being rational about being defensive [18:59] about hearing them and listening and [19:01] reacting about writing docs so that it [19:04] wasn't just hallway conversations like [19:06] okay well you have this concern let me [19:07] actually write it up so that can you can [19:09] scale the [19:10] conversation but but again a lot of the [19:12] thing that was very distinctly apple is [19:14] the secrecy thing and so yeah just put [19:17] in context uh Swift launch in 2014 about [19:21] 250 people at Apple knew about it Apple [19:23] had thousands of software developers [19:26] thousands and thousands and you know [19:28] wasn't just app developers in the [19:30] audience at wwc whose heads exploded [19:32] when Swift launched it was roughly 90% [19:35] of software engineers at [19:37] Apple that's pretty crazy that is so [19:40] crazy You Dropped a feature as much for [19:43] internal Apple employees as for the [19:45] development community at the same [19:47] time by the way we have a new [19:49] language I love that but yeah so that [19:53] was that was an exciting day um uh we [19:56] had prepared the team a bit for that but [19:57] I didn't think we realiz quite how [19:59] interesting that would be but um but but [20:02] you flip it around right you talk about [20:03] decision [20:05] making there's there's lots of ways to [20:07] do it I'm just going to say this is the [20:08] way it worked back then it's way easier [20:10] to make decisions if you have fewer [20:12] Cooks in the kitchen facts yes so having [20:14] to negotiate with thousands of engineers [20:17] in an open culture would have made it [20:18] almost impossible to do anything versus [20:21] being able to get highle stakeholders [20:23] who are used to being rational who you [20:26] know things like this or the people that [20:27] you have to bring in and on board [20:28] because you have critical cross [20:29] functional dependencies and things like [20:31] this and you can kind of uh that's one [20:33] of the things that makes Apple able to [20:35] do uh very discontiguous things you know [20:40] at its best it can do things that nobody [20:41] else can do because um for example in [20:44] the iPhone launch they completely [20:45] sequestered the entire software team off [20:48] from the rest of the company and they [20:49] were able to go innovate and build [20:50] something without having to have a [20:52] million questions about well why not [20:53] this and why not that right that makes a [20:55] lot of sense to kind of force that I've [20:57] worked at simar worked in uh similar [20:59] sized companies and one thing that we [21:01] always did was uh informed Captain [21:04] someone that does farm for descent but [21:06] ultimately just at some point says okay [21:08] this is what we're doing it just it [21:09] doesn't matter what anybody else says I [21:11] am the captain I the captain now I'll [21:13] just say what we're going to do I I do [21:14] like that approach quite a bit all right [21:16] so something you said Chris uh in the [21:18] past on uh I think an interview with Lex [21:19] your second one says Progressive [21:21] disclosure of complexity I really like [21:24] this phrase and how do you apply that to [21:27] like modern language and what does that [21:29] mean and which of our current modern [21:31] languages is the worst at the [21:34] progressive disclosure of complexity oh [21:37] I mean I'll make fun of it because it's [21:40] easy to make fun of but Java is one of [21:42] the most egregious where it's like let [21:43] me show you hello world it's class Fu [21:46] public static void main system.out.print [21:49] lin. Square brackets. this right and so [21:53] like that's that's the failure right is [21:55] it's like okay I want to do hello world [21:56] now I have to know what classes are I [21:57] have to know what packages are need to [21:58] know what a razar I what what is all [22:01] like what this is that that's that's [22:04] what not having this is um so Swift the [22:07] original goal so I haven't been involved [22:09] in Swift development for about uh I mean [22:11] so I left Apple uh you can relate this [22:14] to Mojo too we don't have to relate this [22:16] to well yeah so I'll I'll do both um so [22:19] and I'll tell you Lessons Learned From [22:20] Swift right so Swift the original idea [22:23] was Factor complexity so you have really [22:26] powerful features they're available and [22:28] accessible within the language you don't [22:30] thrust them in people's face you make it [22:31] so that it's simple to get going and [22:33] then powerful as you dig in and so [22:34] Progressive disclosure complexity is [22:36] this UI Paradigm which is you know you [22:39] can have powerful things that are simple [22:41] to learn but then enable power users to [22:45] discover the power as they progress in [22:47] their experience instead of thrusting [22:48] all that complexity into their faces all [22:50] at once and the great thing about this [22:51] when well done is that um it means that [22:57] uh it's not just new user it's also [22:59] experienced programmers you have to put [23:02] Less in your head to get things done [23:03] because um you know normally you don't [23:06] need the complexity or the power right [23:08] um so that was that was a big a big [23:10] focus of my work on Swift and a big [23:13] focus of the other language uh massively [23:15] failed in my opinion by the way so [23:17] massive Lessons Learned Swift has turned [23:19] into a gigantic super complicated bag of [23:23] special cases special syntax special [23:25] stuff and it's all locally well [23:29] intentioned and there are some things [23:31] that they're trying to do with macros [23:32] and things like this to try to put into [23:34] more rigorous framework but one of the [23:36] challenges that Swift ran into and I'll [23:38] tell you what we're doing in Mojo it's [23:40] very different but one of the things [23:41] that Swift ran into is that it um scaled [23:44] the user base really quickly right so we [23:47] launched it and a lot of people were [23:49] ready to get off objective SE let's just [23:51] say right and so found pmf very very [23:53] quickly and so uh and so we got a ton of [23:57] users it had a lot of internal technical [23:59] debt because it was built very rapidly [24:02] and we didn't expect the adoption to be [24:03] so quick and um and so the whole team [24:05] was behind and then instead of fixing [24:08] the core what the team did um both when [24:12] I was there so partially my fault but [24:13] also subsequently is they started adding [24:15] all these special cases um there's also [24:18] some things like uh Swift UI added [24:21] result Builders and stuff like this [24:22] result Builders is a well-intentioned [24:24] metaprogramming thingy uh get rid of [24:27] commas to make Mak some code look better [24:29] on a slide right and so a lot of the [24:31] stuff got added under extreme time [24:33] pressure to enable a feature like Swift [24:35] UI and there are good aspects of it but [24:38] it's one of the reasons that Swift [24:39] compile times are not great and there's [24:41] there's like a bunch of stuff that kind [24:42] of feeds into that as well as just the [24:45] language gets more and more and more and [24:46] more more complicated now so it's still [24:48] a beautiful language it's amazing it's [24:50] got a lot of really great things in it [24:52] but I can't say that it's in a simple [24:55] language and so so now you Channel [24:57] forward to Mojo you say okay well again [25:00] 10 10 years 15 years later Lessons [25:03] Learned right well with Mojo what we're [25:05] doing is we're both building it in the [25:07] open from the start so people can use it [25:09] provide feedback build stuff do this [25:11] we're telling people yes we're going to [25:14] not be stable we're going to optimize [25:16] and build for the right thing right a [25:19] lot of what we do within the team is [25:20] really channel into okay well there's [25:23] all these things people are asking for [25:24] so for example right now Mojo doesn't [25:25] have classes well why we know how to do [25:29] classes like that's like there's nothing [25:32] seriously can definitely do classes [25:33] that's not a big problem but what we're [25:35] doing is we we're drawing a line and [25:36] saying let's focus on this subset and [25:38] make it really really really really good [25:41] before we move on and also a lot of Mojo [25:45] being a python family language python is [25:48] really beautiful and really amazing at [25:50] forcing for example almost everything [25:52] via function call and so Mojo has [25:56] lifetimes has like all these has async [25:58] has like all these things that you need [25:59] to have in a modern language all these [26:01] things are kind of built into the [26:02] function and so if you can do function [26:04] calling right and you get all these [26:05] abstractions right at the bottom level [26:07] of the stack then you can build into and [26:08] compose onto this extremely quickly and [26:11] so my hope is that Mojo remains a much [26:14] simpler actually in practice language [26:17] than Swift is and now you don't have to [26:19] factor the complexity you just don't [26:20] have the complexity so so we'll see how [26:23] that goes I'm very optimistic but um [26:26] also MOJ has much more powerful met [26:28] programming facilities so you know [26:30] there's just a ton of special case [26:32] things like property decorators and [26:33] stuff like this got added to Swift that [26:35] are just kind of special cases of um a [26:39] more broad meta programming feature and [26:41] so you could subsume a lot of special [26:43] cases into you know one proper [26:46] subsystem so many many many Lessons [26:49] Learned From that I mean Swift is a [26:51] beautiful thing uh you know clang C++ [26:53] it's a beautiful thing too um uh but [26:56] it's also a different Epoch of [26:57] Technology ology and you know you talk [27:00] about rust rust is also the same Epoch [27:02] of Technology as Swift and so a lot of [27:04] the lessons learn from going to Mojo or [27:07] learn both from Swift and from rust and [27:10] of course from CL before that which [27:12] Swift learned a lot [27:14] from so with go it is kind of like [27:17] extremely simple uh is that is that [27:21] actually Simplicity or is it kind of an [27:23] illusion of Simplicity that you get [27:24] offloaded into how you have to program [27:26] did you take any lessons from go in kind [27:28] of its you know like almost uh dogmatic [27:32] pursuit of [27:34] Simplicity um I have a ton of respect [27:36] for go um I have a lot less experience [27:38] with go than these other ones um I think [27:41] that go one of the lessons learn from go [27:44] is it initially positioned itself as a [27:45] systems programming language and it took [27:47] them a while to learn that they were [27:49] more of a cloud a cloud platform [27:51] language and um and so um and so some of [27:55] the decisions made around like garbage [27:57] collection and things like this and Etc [27:59] uh make sense given a cloud platform [28:03] language but um but in terms of [28:05] Simplicity [28:08] um I guess the lesson I would learn from [28:10] go and I mean one of the things I was [28:12] shocked at with go is that they actually [28:14] pulled in a generic system and it's [28:16] actually quite good um a lot of people [28:19] including like the Java Community they [28:20] started without generics they kind of [28:22] bolted it on it was never really that [28:24] great and so I was really impressed with [28:26] how they did that and I guess the lesson [28:28] I learned from that is that um what the [28:30] go community did was they drew the line [28:32] for a long time saying we will not have [28:35] generics let's see how it goes without [28:38] this thing let's get a lot of experience [28:40] and instead of saying woohoo let's have [28:42] our first generics model they they they [28:45] were very deliberate about it and they [28:47] learned a lot and then when they did it [28:49] they didn't just measure twice and cut [28:50] once they measured like 200 times and [28:52] then cut once and it turned out really [28:54] good and so I think that that would be [28:56] the thing I'd learned from go is you [28:57] don't [28:58] um just because everybody's telling you [29:00] a thing and this is something I face all [29:01] the time like everybody's trying to tell [29:02] me how to do Mojo or how like the best [29:04] way to do a thing or like how dare you [29:05] do this or like the universal truth of X [29:08] is y and it's like well there there's no [29:10] universal truth there's only trade-off I [29:12] do have some suggestions but we can save [29:14] those for later you know yeah [29:16] totally one thing I was uh kind of [29:19] wondering about sort of along these [29:21] lines of of this disclosure of [29:24] complexity and complexity sort of in a [29:27] language as someone who actually has [29:29] people using your languages and and [29:31] projects unlike many of us and many in [29:33] the chat [29:36] um why isn't functional programming [29:39] popular that's what I want to know I [29:41] love o camel many have been asking me to [29:43] ask you about oel why is it that we [29:45] can't get okl to be as popular as you [29:48] know JavaScript or go or something like [29:50] this I I'm committed to making it happen [29:52] but I'm just wondering what your [29:54] thoughts are I love o camel I wrote a [29:56] scheming for o camel a million years ago [29:59] made it properly tail recursive like o [30:02] cell is actually my favorite uh ml [30:05] functional language I'm just gonna cut [30:07] it to say o cel's actually my favorite [30:09] I'm getting the clip later we're putting [30:10] it on a t-shirt o cel's my favorite [30:12] Chris lner we're we made it Al I'm also [30:16] a huge fan of hcll and things like this [30:18] but for different reasons and okel I [30:21] think is a [30:22] much like I like that it's strict I like [30:24] that it is uh much simpler than the hcll [30:28] ecosystem and things like that um so the [30:31] the challenge with okam and um Jame [30:34] Folks at Jam Street and a bunch of other [30:35] people working on this but okel still [30:37] doesn't do threads well I mean I think [30:39] they're getting there um it still has a [30:42] it's very com so okam endlesss and [30:45] things like this don't work with modern [30:47] computers very well because everything [30:49] ends up being boxed and indirected [30:52] through pointers and so these days [30:54] unlike 30 years ago we have multi-level [30:56] caches and it turns out you know when I [30:59] was a kid I was taught algorithms and [31:01] it's like here's the algorithmic [31:02] complexity of a link list and here's the [31:04] algorithmic complexity of an array and [31:05] if you insert into the middle of an [31:06] array it's really slow if you insert in [31:09] the middle of a link list it's really [31:10] fast right that's generally wrong today [31:14] right because an array is all next to [31:17] each other in memory link list is [31:18] everywhere and so on a modern computer [31:19] if you even just walk a link list it'll [31:21] be 100 times slower than walking a ray [31:23] you know so so yeah it's technically [31:26] true at massive size is but um but a lot [31:29] of a lot of uh computer architecture [31:32] shifted the way you actually have to [31:34] write code and and things like oaml and [31:36] Lis and things like this are kind of [31:37] from that previous gener thing and so um [31:40] I don't know if it's answering your [31:41] question I love OK camel I think it's [31:42] amazing I think that it made um you know [31:45] pattern matching for example which is in [31:47] now many languages but a lot of these [31:49] good ideas were kind of buried in the [31:51] functional programming world for a long [31:52] time and um Swift brought some of that [31:55] forward which I think was really [31:57] fantastic andh rust also and many other [32:00] more modern languages are rediscovering [32:01] all this kind of stuff and so um I think [32:04] it's awesome [32:06] but I'll reemphasize I want to [32:08] reemphasize your question which is why [32:10] don't you think functional programming [32:12] even just as a concept catches on [32:14] because everyone who does functional [32:15] programming like starts wearing tie-dye [32:17] t-shirts and like gets converted to the [32:20] Church of functional programming almost [32:22] immediately so like why hasn't it caught [32:24] on okay so you want me to piss off your [32:26] entire community absolutely just 12 [32:30] users there's only okay it's yeah it's [32:33] because it's because functional [32:34] programming strictly defined is dumb [32:37] like it doesn't actually make sense is [32:39] that is that is that polarizing enough [32:41] for great more [32:45] more so so again I'm being hyperbolic [32:48] right but the uh but here's why right [32:52] so so much of computing is about [32:56] defining mutable State and managing [32:58] functional programming says cool you can [33:00] do that and the way you manage mutable [33:01] state is by making an entire copy of the [33:03] data structure with the changes in the [33:05] new copy of the data structure this is [33:07] what generally people mean by functional [33:10] programming although you could Define in [33:12] lots of other different ways right and [33:13] so if you say it's purely functional [33:15] what that does is that means you have no [33:17] inplace [33:18] mutation okay here's the problem [33:22] computers they're all bags of mutable [33:25] State and so if you're saying I'm going [33:27] to reallocate and copy the entire data [33:29] structure to make a change somewhere in [33:31] a tree well it's just extremely slow and [33:35] so again back in the day maybe it was [33:37] okay and and for many youth cases it's [33:39] fine obviously right but but what Swift [33:42] did was Swift moved from let's have [33:44] functional programming to let's have [33:46] value [33:47] semantic and I probably don't want to go [33:49] into it deeply here but value sematics [33:51] are strictly more powerful than that [33:53] form of functional programming because [33:55] you get separation and logical [33:58] composition of behavior like functional [34:00] programming gives you but you also get [34:02] in place mutation and so it's a strictly [34:05] more powerful model it is uh much faster [34:08] in practice and obviously scaled to [34:10] millions of people and things like this [34:11] and so um so I mean so there are better [34:15] things than that that form of functional [34:17] programming now it's also super funny [34:19] because when you say what is functional [34:20] programming well some people say scull [34:21] is functional right and lots of lots of [34:23] schol programmers identify as functional [34:25] programmers even though they don't have [34:27] lack of M ation they don't it's not what [34:29] what you would cons like okel or hll is [34:32] is that right I mean a hll programmer [34:34] would say that that okam isn't properly [34:37] functional because it's not strict right [34:40] and it has mutable Fields so you can [34:42] update in place so it would be no longer [34:44] functional yeah yeah and so and so like [34:47] again like there's a holy war aspect [34:48] here but what what when I say functional [34:51] programming is done what I mean is in [34:53] practice like making an entire copy of a [34:56] data structure to change one part of it [34:57] like that that doesn't actually work [34:58] well for modern large scale applications [35:01] and so that that one little piece is is [35:03] that now I love all the people and so [35:06] they'll attack me for saying this but [35:08] that's okay I can take it I think um one [35:12] one I think if we if we can maybe Prime [35:15] if you're if you think it's good to just [35:17] like camp out on value semantics for [35:19] like five minutes because I do think [35:20] it's really cool and it goes with some [35:21] of the things from Mojo too as well as [35:24] how Mojo sort of does and and and sort [35:27] I've seen this popping up in a lot of [35:29] languages now obviously rust has this [35:32] has a lot of ideas about ownership and [35:33] borrowing Mojo has it now as well I see [35:36] you guys are working on different stuff [35:38] with how to manage refs and are refs [35:40] going to be transparently access okay [35:42] you got a bunch of stuff going on there [35:44] we can talk about those that's coool o [35:46] camel is um is adding this as well in a [35:49] way they have this oxidizing o camel [35:51] project where they're adding um like [35:53] locality and ownership so that they can [35:55] allocate on the stack instead of the [35:57] Heap there's like a sort of an explosion [36:00] of I think this concept across a lot of [36:02] languages so maybe you know give us your [36:04] pitch on what is and why value semantics [36:07] are cool because uh I I like them as [36:10] well yeah so I mean just uh I mean let [36:14] me give you a simple example you have an [36:16] array in a purely [36:19] functional system if you have an array [36:21] with 100 elements and you want to set [36:22] one value into the array you have to [36:24] copy 100 elements or you have to copy at [36:26] least the array part which points to the [36:28] elements something like this right and [36:29] so uh functional programming done [36:33] strictly that way destroys otation [36:36] destroys the the performance of your [36:39] program um so then what ends up [36:42] happening is that uh if you're building [36:45] into one of these systems you start [36:46] adding tons of complexity to work around [36:47] it and so I've built and maybe you have [36:51] as well like lots of really fancy [36:52] immutable data structures and there's [36:54] ways to use PR instead of arrays and [36:58] you know beef frees are like one of the [37:00] most under preor ever if you want to go [37:03] there but the uh um but it's just huge [37:06] amount of complexity and if you can do [37:07] in place mutation because you know you [37:08] have the only access to an array then [37:11] you totally can directly mutate it and [37:13] it actually composes out really well and [37:16] it just is better for ux it's better for [37:17] performance it just leads to a better at [37:20] scale programmers couldn't have to know [37:22] everything and know there's five [37:23] different ways to have an array they [37:25] just have an array makes it way simpler [37:27] and so mhm um but now what what it [37:30] requires is it requires either having [37:32] strong ownership like a rust or a Mojo [37:35] has for example or or being a little bit [37:37] Dynamic and then requiring you know [37:39] building on fancy compiler optimizations [37:41] and so Swift is in the being a little [37:43] bit Dynamic and then relying on fancy [37:45] compiler optimization camp and so that [37:47] it works really well for the Swift [37:48] community and and it's scaled really [37:50] well and I'm very happy about that um [37:52] but uh a lot of people don't want [37:54] Dynamic effects and stuff like this and [37:56] so if you can if you're up for more type [37:58] system annotations and stuff like that [38:00] then you can go with the I know I have [38:02] unique ownership kind of approach and [38:04] that that's also cool um one of the [38:05] things I'd like to achieve in Mojo is a [38:07] hybrid of both or you can have F Dynamic [38:10] thing for you know python programmer [38:12] just wants to write normal code and [38:13] doesn't care about a little bit of [38:14] overhead but then you you opt into more [38:17] strict annotations and now you can fully [38:19] control everything and the embedded [38:20] systems programmer gets all the overhead [38:22] out and if you can blend these two [38:24] worlds together then you get something I [38:26] think is the best of both worlds and it [38:29] kind of goes back to that Progressive [38:30] disclosure complexity right we want to [38:31] make it so the python you know that most [38:33] programmers most code written by most [38:36] programmers doesn't actually matter for [38:37] performance and so if that's the case [38:39] then hack something out have a lot of [38:41] fun go go nuts and then if you want [38:43] performance you can layer and type [38:44] annotations or things like that and just [38:46] get it over time and so this has been [38:48] done in many different systems over time [38:50] it's just never been done in the python [38:52] world because or I should be careful [38:55] what I say everything's been done in the [38:57] python world so uh but uh I would say [39:01] it's not been widely used in the python [39:02] world because um because of certain ways [39:05] that the type annotations work and [39:07] things like this which are a little bit [39:08] goofy in that system yeah that totally [39:11] makes sense I'm kind of [39:13] wondering along this line of the you [39:17] know you sort of start with python as [39:19] sort of this goal of Mojo it's a super [39:21] set of python eventually right and um [39:25] how do you prevent Mojo from becoming [39:28] python Plus+ if that's a clear question [39:31] related to C and [39:33] C++ yeah totally well so I think it it's [39:36] let me flip it around it is actually a [39:38] strong goal for Mojo to become a python [39:39] Plus+ that is the [39:41] goal right and so people ask me all the [39:43] time the other side which is your mojo [39:45] is the super set of [39:47] python uh how do you handle the fact [39:50] that python will keep changing Python's [39:52] not a dead language that was our fall [39:54] question yeah got it yeah and so and so [39:58] how do you square with this and so the [39:59] analogy I always give is look at C and [40:02] C++ C+ C was around for decades when C++ [40:06] came about C++ was C with classes and [40:09] their whole idea was let's add classes [40:10] and then eventually templates and stuff [40:12] like this but it was a different [40:14] community that got standardized as a [40:16] different language and here you're [40:18] talking about running a committee speed [40:19] so it's glacial by today stand standards [40:22] but um but what end up happening is the [40:25] two languages and the two communities [40:26] were super were aware of each other and [40:28] people cohabitated you know programmers [40:30] cohabitated both Community right and so [40:32] what ended up happening is um classes of [40:35] code were built that work in C and C++ [40:38] and then some people decided to go for [40:39] C++ because it added value right but uh [40:43] a lot of people don't know this but a [40:44] lot of features FL went both from C to [40:47] C++ obviously but also C++ back to C so [40:51] in C you have the void keyword for [40:53] example uh that was a C++ invention [40:57] but then see adopted so know that like [41:01] yeah and so there's a lot of things that [41:03] that that happen when you have two [41:04] communities with different objectives [41:07] and the the key thing you want is stay [41:09] true to your objective stay true to your [41:11] Charter be again I'm not anti- python [41:14] we're not trying to kill python I think [41:16] Python's amazing I love it um but we're [41:18] trying to solve the C and C++ and Cuda [41:21] and other parts of the Python ecosystem [41:24] in in one language that can scale [41:25] instead of saying okay here's the uh [41:28] glue layer and here's the actually get [41:30] stuff done layer and you have to use two [41:32] different layer languages to be [41:35] productive in terms of that like C C++ [41:39] sort of comparison like [41:41] c i I mean maybe I maybe it has I'm not [41:44] aware of any like basically never it [41:46] feels like breaks backwards [41:47] compatibility even maybe to its uh [41:50] detriment but like python sometimes does [41:53] maybe they're a little more hesitant to [41:55] do that these days uh than they used to [41:56] be like has there been any example since [41:59] you started Mojo or any example you sort [42:01] of see along the horizon of like python [42:04] breaking something where then you're [42:06] like oh how are we going to handle this [42:08] fact that like python 310 does this and [42:10] 312 does this and we need Mojo to run [42:14] like in both or is it like oh you can [42:15] only run Mojo with 312 or something like [42:18] H how is Mojo balancing those yeah so so [42:21] Guido is the one that scrolled me the [42:22] most on this by the way he's a guy that [42:25] cares a lot about python longterm [42:27] sustainability and compatibility and he [42:28] has all the Battle Scars to to share so [42:32] so there's two places where [42:34] compatibility with python matters for [42:35] Mojo so right now today in Mojo you can [42:38] import an arbitrary python package and [42:41] it just works okay and so this allows us [42:44] to embrace the entire python ecosystem [42:46] you don't have to write ffi or bindings [42:49] or wrappers or just works the way we do [42:52] that is we parse and interpret the [42:55] imported python package [42:57] with [42:59] cpython we just keep the standard [43:01] interpreter as it is and now there's a [43:05] separate pit of complexity on how do you [43:07] manage your python but we can't we can't [43:12] we can't fix cpython cpython is the [43:14] standard implementation of python with [43:16] The Interpreter and things like this [43:17] okay now fortunately there's a ton of [43:19] people working on cpython Lots people [43:21] trying to make it better trying to [43:23] remove the Gill which would be awesome [43:24] for Mojo by the way there's like a bunch [43:26] of work around python we don't have a [43:27] lot of value to add there right there's [43:29] the huge huge community of people doing [43:30] all that kind of stuff and so but what [43:32] we can do is we can use their public [43:34] apis and so we can talk to the the [43:36] python interpreter through niely stable [43:39] things and then python can go ahead and [43:41] change itself and it's fine it doesn't [43:43] doesn't matter to us at all um now [43:46] things like no Gill and stuff like that [43:48] are uh do change some things and so we [43:51] have to do minor adaptation in you know [43:53] for the big changes but no Gill is like [43:55] a five-year Quest or something thing for [43:57] Python and so like we can we can adapt [43:59] to things like that's fine um like I [44:02] said it takes less than five years to [44:04] build an entire [44:05] language you know um so the other side [44:09] of it though is we want to make it [44:10] really easy to move code into from [44:12] python into [44:14] Mojo and so as Mojo grows into a super [44:17] set of python which is not right now [44:20] right now it has no classes that's a [44:22] pretty big feature hole it's a tough one [44:25] no list comprehensions which you know [44:27] makes makes us sad I like writing them I [44:29] don't like reading them you know but [44:31] anyone who likes python says not to [44:33] write classes so at least you've picked [44:34] a good feature not to to implement right [44:37] I don't know about that yeah yeah that's [44:39] okay you can you can polarize people but [44:41] the I actually think class are pretty [44:42] cool but the uh uh but so anyway so so [44:46] we're not there yet but and so because [44:48] we're not there yet basically when [44:50] people move python code to Mojo like [44:53] they have to do a little bit of [44:54] rewriting right they they have to change [44:55] a class into inst struct have to do some [44:58] adaptation but what we've seen in the [44:59] community is people can move depending [45:01] on the kind of code right people can [45:02] move code really rapidly and it's really [45:04] easy and so you have to kind of learn [45:06] some of the tricks but once you do that [45:08] it doesn't take a lot of work and a lot [45:09] of it is because Mojo is it's different [45:11] in places where it needs to be different [45:13] where it's adding value but otherwise we [45:15] stay the same as Python and so one thing [45:18] I I'll share with you one thing I so I [45:19] generally love python python I think [45:21] it's a beautiful language one thing that [45:22] I don't super love is the postfix if [45:26] thing you say it's like X if condition [45:30] else y like I don't right just Square [45:33] honestly I don't love that but but guess [45:35] what that's what python does and so [45:36] that's what Mojo does let's not debate [45:39] it that's the thing right and so because [45:41] of that right what it means is that if [45:43] you're experienced with python whether [45:44] you love all the pieces or not like it [45:46] it makes it much easier to bring over [45:48] and L comprehension yeah will do that [45:50] it's we just haven't gone around to [45:51] either yeah now when you grow into a [45:53] full superet right that's I think what [45:55] you're what you're asking about as well [45:57] and then you say okay well now I'm [45:58] moving things from [46:00] python 3.85 to whatever you know and and [46:05] how does that handle and stuff like this [46:06] and so for that we can have so the the [46:09] the idea and this is a lesson learned [46:11] from Swift by the way is to have [46:12] migrator tools so it's not that the code [46:15] magically works like in Mojo we're [46:17] taking a new keyword right you can [46:20] decide what the new keyword is but we [46:22] want to be able to do that um that's [46:24] very important to make the language [46:26] consistent and coherent and things like [46:28] this and so we don't want to be ashamed [46:29] of doing that we want to do the right [46:31] thing for Mojo and so what we can do is [46:33] we make it so that okay there's a [46:35] mechanical tool that you run but then [46:36] just escapes the keyword adds an [46:37] underscore to it or something right if [46:39] you're using it and so we can make it [46:40] super easy to mechanically import and [46:43] that tool can then have a verin flag [46:45] that makes sense and also going back to [46:47] Swift right Swift was incompatible with [46:48] itself for multiple years and so uh as [46:51] as it came out with um with new new [46:54] features and it broke code what we did [46:56] was we provided a migrator the migrator [46:58] par old Swift Code and upgrade it and it [47:00] did a I don't know 90% job not 100% job [47:03] but it was still very useful and to help [47:05] the community move over and so this is [47:07] also the way I look at eventually being [47:09] syntax compatible with python is um you [47:12] know we technically will not be a [47:14] superet because we take a new keyword or [47:16] something um but guess what C++ is [47:18] technically not a super set of C either [47:20] correct it takes new keywords and so [47:24] it's fine like we as a community can [47:25] manage that it's not that big deal yeah [47:28] kind of Switching gears here uh yeah you [47:31] obviously have created a lot of really [47:34] large projects and these are these [47:36] aren't just weekend projects they are [47:37] multi-year projects and they're still [47:39] going on today and you've done a lot [47:41] you've you've stated that you learn by [47:42] building and so you said how hard is a c [47:45] compiler so you just started working on [47:46] it in nights and weekends and all that [47:48] and there's a lot of questions here that [47:50] I'm sure people would love to ask which [47:51] is like how do you choose your side [47:53] projects how do you stay motivated to [47:55] complete these but before you answer any [47:57] of those could you could you just kind [47:58] of give us like how do you even manage [48:00] your time exploring these new Concepts [48:03] versus working on the things that are [48:05] already huge to begin with such as like [48:07] how do you switch from llvm to the next [48:09] thing how do you switch from Swift to [48:11] the next thing without just getting [48:13] bogged down with all these like requests [48:15] for new things or your insights into [48:17] things so I thought you're GNA be nice [48:19] to me and now you're pointing out that [48:20] I've like an attention problem and I [48:22] can't stay something for more than eight [48:25] years [48:26] all you need attention is all you need [48:29] there you go um well all seriousness um [48:33] so I'm unusual in many ways um you know [48:37] the one of the ways that I'm unusual is [48:39] that I love to build things understand [48:41] them but I also do get along with humans [48:43] sometimes and I try I try hard and I'm [48:45] learning I'm getting better as I as I [48:47] grow and so um take take Swift for [48:50] example right um in the case of Swift it [48:52] was nights and weekends project for a [48:54] year and a half at that time I was [48:56] managing a team of 40 people or [48:58] something I don't remember exactly with [49:01] you know the the debugger which is [49:03] itself a team the clang stuff with [49:05] Objective C and C++ and all that kind of [49:07] stuff and um LV we built an entire code [49:10] generator for Apple's gpus to make it so [49:13] that Apple could insource its Hardware [49:14] design and so tons any there's tons of [49:16] stuff going on within my team maybe it [49:18] was bigger than I don't remember but the [49:21] uh um and so like I had a day job but uh [49:25] but each of those projects [49:27] um had gone from being something that [49:30] got catalyzed something got built out [49:31] something got proved and validated to [49:33] now there's a whole team around it that [49:34] was building it and they're doing it [49:35] better than I was right and so I me me [49:38] trying to be an engineer on the team as [49:41] a poter her boss as a managers or [49:43] whatever it's these amazing Engineers [49:46] full-time job like I add a lot of value [49:48] the value I adding is maybe architect [49:51] maybe as helping with problem solving [49:54] pointing them the right way classical [49:55] manager Tech lead manager type of rules [49:59] and uh me as a technologist like I like [50:01] to build things like You're were talking [50:02] about and so that means I then start [50:05] looking around and saying okay well [50:06] what's the next logical thing to work on [50:07] and so um that's where again clang clang [50:12] or Swift or uh uh things like this it [50:14] was more about it's no okay there's no [50:18] ambition for it to become anything big [50:19] it was more about just build some stuff [50:21] see see where it goes when Swift you [50:22] know i' work at it for a year and a half [50:24] it wasn't because ah I want to do world [50:26] comination it's more it's more about [50:28] okay well let's just see see what what [50:30] there is to do here and I have some [50:32] ideas let's prototype some stuff let's [50:33] have some fun and build in it's very [50:35] fast when you only have something in [50:37] your head you can spin very quickly and [50:39] you don't have to have meetings and so [50:40] it's very fun in a different way but [50:42] then to your point what happens is then [50:43] you want to get beyond what you can do [50:45] in your spare time it becomes more [50:47] important you understand it you can [50:48] explain it then you start bringing more [50:50] people there becomes a team then there [50:51] becomes a tech lead or a manager and [50:53] then and then at that point I can grow [50:55] out of it and do this [50:57] um one of the things I've [50:58] discovered across the years which is not [51:01] obvious is that um because I've kind of [51:03] been in this role of like invention [51:06] creation Innovation for so long um it [51:10] it's super funny I for example I was [51:12] working with the team at Google we're [51:13] building high performance runtime for [51:14] machine learning stuff and um like just [51:18] getting within the Google confines the [51:21] approval air quotes which was massively [51:23] not defined uh of like consensus of yes [51:27] we should build a new runtime for [51:29] tensorflow like achieving that was this [51:31] massive heroic effort just political and [51:33] just gigantic mous um we got consensus [51:37] to do this and then got the I had a team [51:40] and it's like okay team go and and it's [51:44] like space is clear let's go let's go [51:46] build this thing it's really important [51:47] go right and I was doing a bunch of [51:49] other things at the time I'm like hey go [51:52] right and and nobody could do anything [51:55] and what I realized [51:57] is that again brilliant Engineers right [51:59] this is again Google and um working on [52:02] machine learning infrastructure and high [52:03] performance accelerators and tpus and [52:05] stuff like this what I'd realized over [52:07] time is that um these amazing Engineers [52:10] had only ever worked on a mature project [52:13] it only added a feature or fixed a bug [52:16] or they jumped into a big code base [52:18] particularly at Google um you know the [52:20] the strong Engineers the experienced [52:22] Engineers like their major feature is [52:23] that they can absorb a huge amount of [52:25] complexity fit in their head and then [52:27] figure out the way to logically hill [52:29] climb the thing that they have and [52:31] outside of college very few people have [52:32] the opportunity to build something from [52:34] scratch so you're sitting there and [52:36] you're saying okay in front of us is [52:38] this you know I'm standing on the edge [52:39] of a cliff looking off into space you [52:41] know like and and to me I'm like oh I [52:44] can see a castle over there and I can [52:46] see this thing over here and I can see [52:47] how this all goes together and for other [52:49] people it's just terrifying because they [52:50] didn't know where to start and so [52:51] there's all these um again what I've [52:55] across the years because [52:57] you know getting more experience with [52:58] things um there's these patterns and [53:00] what I've seen is that there's folks [53:01] that will start from space and just be [53:03] paralyzed there'll be other folks that [53:05] just say like oh okay well I'm going to [53:06] build a new thing well there's this old [53:08] thing I've already worked on I know that [53:10] it works let's just reimplement that and [53:12] so the thing I like to do is I like to [53:15] say okay well we're GNA build a new high [53:17] performance machine in own time or a [53:18] language or whatever the starting point [53:21] for me is not um go hack up the thing [53:24] that I saw before it's go study all of [53:27] the things now when I was working on [53:29] Swift it was so was great you know was [53:33] kind of in parallel with grade and [53:34] working on Rust and things like this um [53:36] but also there's a bunch of other [53:38] languages that were really cool both [53:39] modern and also like okam for example [53:42] yes to fan and hle and things like this [53:44] but also uh really older ones as well [53:47] like some of the fundamental ones like [53:48] clue clu and things like this that many [53:51] people don't remember and so going and [53:53] studying and looking at um like Dart for [53:56] example right it's a very in very [53:58] specific domain that it wants to live in [54:00] and it makes a bunch of decisions it's [54:02] very specific to the problems it's [54:03] trying to solve but the way it did [54:05] Unicode escape and strings is really [54:06] cool and so we said yoink I'm G to take [54:08] that and put that in Swift and that's [54:09] the best way to do it way better than [54:11] what SE did or whatever it is and so my [54:13] Approach is generally do that research [54:15] do that survey and build a picture you [54:17] know build that what that castle looks [54:19] like out in space so I know what I'm [54:21] trying to get to and then iterate and [54:23] refine it over time and so I don't even [54:25] remember what your question is more but [54:27] um that's okay I have a good followup [54:29] anyways uh so I think this is like one [54:32] of the biggest weakness of all Engineers [54:34] is not knowing when to quit which is [54:36] either they quit too soon or they quit [54:38] too late how do you know what like [54:41] staying up for a year and a half on [54:43] nights and weekends programming Swift [54:45] when did you know like oh I shouldn't [54:47] quit this or how do you know oh I should [54:48] quit this and pursue something different [54:50] like what what is that kind of uh [54:53] thought process you have for quitting [54:56] well let me give you let me give you a [54:58] uh a modern example of modular so I [55:02] assume most of your folks don't know [55:03] what modular is about and so I'll give [55:04] you some context right so uh uh context [55:08] here is that AI is exploding super [55:12] annoying in lots of different ways [55:13] because there lots ofz and stupidity and [55:16] stuff like this floing but the systems [55:19] level the foundational infrastructure [55:21] underneath it is very profound very [55:22] important and AI despite some of the [55:25] Annoying stuff is also so really [55:26] important and there are really important [55:28] use cases at scale for businesses and [55:30] there's there's a big there there okay [55:33] now the problem with it is that the [55:34] technology platform this is all running [55:35] on is a gigantic freaking meth and [55:38] there's Cuda for example there's like [55:40] you know when training there's still [55:42] things like MPI and there's like all [55:44] this stuff is just this gigantic [55:46] nightmare of Technologies and it's and [55:48] it's never been really thought out and [55:50] so one of the things I realized is um [55:53] actually gave a talk several years ago [55:56] this as plus conference and if you want [55:58] you can find a link uh it was 2021 um I [56:03] gave it I gave a talk about you know [56:04] it's the Golden Age of compilers because [56:06] there's all this hardware and what we [56:09] need to do is we need to build a [56:10] unifying theory that allows us to [56:12] innovate in hardware and be able to get [56:15] all this stuff you know get software [56:17] developers to be able to build on a [56:18] common platform so that you can then uh [56:20] scale across all the different kinds of [56:22] Hardware because most of us all software [56:24] Engineers don't want to rewrite in our [56:25] entire app every time the thing changes [56:28] right the the hardware changes right we [56:29] want we want this and also by the way [56:31] the hardware people don't want to [56:33] reinvent an entire software stack every [56:34] time they want to come out with a new [56:35] chip basic observation and so um and so [56:39] when we started modular we said let's [56:40] how do we solve that problem and so here [56:43] here's here's the [56:45] Ridiculousness you know because you're [56:47] giving me a hard time you're saying [56:48] Chris you do these possible things right [56:52] um actually push this on stack like and [56:55] give you an example it's like like when [56:56] I joined Apple at a school to work on LM [56:59] like within the first month the very [57:01] senior lead of the GCC team comes up to [57:03] me and says Chris why are you working on [57:05] this lvm thing it's an academic research [57:07] project hundreds of people have been [57:09] working on GCC for decades like you're [57:12] doomed to failure why are you even [57:14] bothering just work on GCC right and [57:18] when working on Swift it's like [57:20] languages never work right again it's [57:22] phrase generally more passive [57:23] aggressively than this but new languages [57:25] never work nobody ever adopts them [57:27] languages are too expensive to build [57:28] blah blah blah you're doomed to failure [57:30] and so I've been told I'm doomed to [57:31] failure so many times it's it's I'm I'm [57:34] pretty used to it um Twitter only [57:36] amplifies it and makes it more frequent [57:38] but it's all good um and so with modular [57:41] you go into this you say well what is [57:42] our objective our objective is not just [57:45] to build a unifying platform for this [57:47] next Generation heterogeneous compute [57:48] CPUs gpus accelerators all these new [57:50] things are so important to the world but [57:53] it's to beat the state-of-the-art of the [57:55] hardware vendors on their own [57:58] chips well how do you do that you talk [58:01] about rust how can you be faster than [58:02] rust like how can you be Intel who's [58:04] been building software for their chips [58:06] for 20 years they know their chips [58:08] better than anybody else how can you be [58:09] Intel in their own chips right and so we [58:12] started out with the company is we said [58:14] okay well let's go we have a hypothesis [58:16] that we can do this and how what how's [58:18] the hypothesis shaped well um built a [58:21] new compiler framework called ml which [58:23] is kind of like you can think of as like [58:24] a successor to lovm [58:26] it was really cool really profound [58:27] nobody understood how it [58:29] worked there's a bunch of new algorithms [58:33] there's a bunch of ways to be able to [58:34] generate code when you get into this [58:37] accelerator space and the high [58:38] performance compute even on CPUs um you [58:40] have to use the hardware blocks like [58:42] because all these things have matrix [58:44] multiplication operations now and like [58:45] all the stuff is built into even CPUs [58:47] but definitely accelerators right so the [58:49] entire game which by the way none of [58:52] Swift or rust or any of these languages [58:53] even attempt to solve they can barely do [58:56] simd U but the entire game is how do you [58:59] actually utilize a modern computer and [59:02] now your multicore on servers you have [59:04] multiple sockets and so you have what's [59:06] called Numa so the memory access [59:08] patterns are very different depending on [59:10] where you're doing your accesses from [59:12] and so nothing in this world has been [59:13] designed for this kind of computer and [59:15] you look at um again I'm not anti- inel [59:18] or anything but you look at General [59:20] hyper software and it was written for [59:22] tips 20 years ago and so what we did [59:25] coming back your point of how do you [59:26] know when to quit because we said okay [59:28] let's build some really crazy ass [59:31] high-tech stuff that nobody else in the [59:33] world knows how to do like very [59:35] different architecturally yes you need a [59:37] high performance asynchronous runtime on [59:38] the bottom yes you need a entirely new [59:40] threadpool you need you need an entirely [59:42] new way to program simd you need an [59:44] entirely new way to uh generate code and [59:47] do automatic what's called fernal Fusion [59:49] so you get rid of memory traffic [59:50] entirely and things like this let's [59:52] build this really fancy compiler thing [59:54] and in in in a way that we could show [59:57] that we could generate Matrix [59:58] multiplications that run faster than [60:00] Intel Intel mkl on Intel [60:02] chips and we built all that kind of [60:04] stuff out and like good scientists and [60:06] you want to validate the hypothesis and [60:09] so we we built this really fancy [60:10] compiler stuff um that nobody else has [60:13] and then we showed and we proved to [60:15] ourselves that yes we could beat Intel's [60:17] best Drag Racing on their chips even [60:20] though they have thousands of like [60:23] insanely amazing people writing an [60:24] assembly code um and that what we proved [60:27] is that the generality of a compiler [60:30] beats humans special casing individual [60:32] Point Solutions because humans can't [60:34] scale the compiler can scale and this is [60:36] again a very different generation of [60:37] Technology than something like lvm right [60:40] and so the problem then we had was we [60:42] got to the end of uh this was the end of [60:44] 2022 and we said cool we have this [60:47] really fancy compiler stuff we can do [60:49] this we can generate code problem is [60:50] that there's like three people in the [60:52] world that can possibly understand this [60:53] because you have to be able to [60:54] understand all of the compiler and all [60:56] of this crazy stuff and we we validated [60:58] that yes we can do it so let's not stop [61:00] but then we said well how are we now [61:01] going to program this stuff and then we [61:03] said well I need [61:06] syntax and then we went shopping for [61:08] syntax and then we decided Python and [61:10] then dot dot dot that's what Mojo [61:13] is right and so Mojo was not Mo Mojo is [61:17] not a like let's go build a language for [61:19] fun Ojo was a solution to a series of [61:21] equations of we have this really fancy [61:24] compiler stuff built forne generation [61:26] acceler and gpus and all this kind of [61:27] stuff now we need syntax and python is [61:30] the obvious syntax but we can't use the [61:32] python implementation or the Swift [61:33] implementation or any of these compilers [61:35] because they don't have any of the right [61:36] guts inside of them and so that's that's [61:39] the world that Mojo is coming out of one [61:41] of the interesting things about Mojo I [61:42] think this probably the last one before [61:44] we move Prime is my understanding is [61:45] Mojo is like effectively just an an as4 [61:50] ml right that's what you've said before [61:52] there's sort of like it's a direct like [61:55] link to mli [61:57] that that is true um but that really [62:00] under so that that is absolutely true [62:01] and there's an incredibly valuable thing [62:03] about that which I expect most folks [62:05] won't won't grock but uh many of today's [62:10] systems whether it be on your desk like [62:12] you know an apple silicon thingy but but [62:15] also these very fancy data center [62:18] accelerator things they're very [62:19] different computers and so the way you [62:21] need to program them is very different [62:22] and ml is the right way to do that the [62:26] problem with ML and this is another [62:28] thing that annoys me to no end is that [62:30] ml which is now an lvm Pro so it's part [62:33] of the lvm Ella has all this super [62:35] academic crazy stuff in the in the [62:38] project and and we use almost none of [62:40] that we don't use the ml dialects at all [62:43] and so not only do we not only are we [62:46] the only language that front ends to ml [62:49] which is itself a very important thing [62:51] when talking to all the asex and stuff [62:53] like this but we've rebuilt the entire [62:55] compiler stack from scratch and so this [62:57] is again when you say how can you be [62:59] faster than x it's like well we have a [63:01] completely different stack we've built [63:02] from scratch it's it's it is actually [63:05] new technology and I think that's where [63:07] people are I mean maybe it's part of the [63:09] success of lvm is everybody just buildt [63:11] on top of LM and they're like they're [63:12] all the same and so people like oh okay [63:14] well languages are all the same if [63:15] they're zero cost subtractions and it's [63:17] like well that's true if you're all [63:19] using the same code generator but if [63:21] you're doing something new then it's not [63:22] all the same so that's a great answer I [63:26] I now submit that Mojo can be faster [63:28] than Russ now that I know that you're [63:30] swapping out what uh what car you're [63:32] driving yeah yeah and and again lvm is a [63:35] good thing but lm's 20 plus years old [63:38] right I mean it's it's it's a good thing [63:40] and I mean I'll just speak for myself [63:42] I've learned so many [63:43] lessons and very proud of what it's been [63:46] able to do and it's contribution to the [63:48] world but it's not it's not perfect by [63:49] stretch of imagination I know I know the [63:52] problems better than anybody um in fact [63:54] if you if you look at the lvm developer [63:58] meeting uh last fall we gave a talk [64:00] about Mojo and we explained it's like we [64:02] use lvm the good parts not the lvm [64:08] system well thank you very much Chris [64:10] for joining us uh for the remainder of [64:12] the time because we have you just for a [64:13] little bit longer I know you got a [64:14] something here in about 20 or uh yeah [64:17] about what is that 19 minutes uh we're [64:19] going to switch over to the Discord uh [64:21] I'll stop The Stream and then I'll walk [64:23] you through exactly what to do and we'll [64:25] feel a couple questions from the top [64:27] shelf for those that are on the top [64:28] shelf that would be tier 2 tier 3es from [64:30] twitch you get to go over and then [64:32] anyone that has a sufficiently neurotic [64:34] question I will then ask Chris that [64:36] question and we'll see how it goes uh [64:38] all right hey thank you very much for [64:39] coming on really appreciate it by the [64:41] way just it absolutely just a treat to [64:43] talk to you and just the things you've [64:45] accomplished are truly an inspiration to [64:46] a lot of people in the chat a lot of [64:48] people said you've made like you were an [64:51] inspiration for Part of Me programming [64:52] and all that so thank you for everything [64:54] you do that's amazing yeah Al so I mean [64:56] I I'm very happy that the things my Nery [64:58] little projects are interesting and [64:59] useful for people and so it's it's [65:01] amazing they're not just useful they're [65:03] I mean we wouldn't have a lot of our [65:05] modern languages without it so I love [65:07] Zig and Zig is currently on lovm so I'm [65:09] sure I don't even know if it would be [65:11] possible to have Zig without that in its [65:12] current state so thank you I I I also [65:16] love Zig so um ask so many questions [65:19] about Zig oh man yeah well a lot of Zig [65:22] is in Mojo including the entire meta [65:24] programming system so I mean that's [65:26] comp we'll talk about it in the top go [65:29] to the topop getting distra this is this [65:31] this is again people are not used to the [65:32] fact that progress is being made all the [65:34] time and so you have to learn from it [65:38] all right awesome all right hey [65:40] everybody thank you for joining uh we're [65:42] off to the Discord