#381 – Chris Lattner: Future of Programming and AI | Lex Fridman Podcast (2023-06-02, gemini-2.5-pro)
1. 导读
Chris Lattner 是编程语言与编译器领域的传奇人物,他是 LLVM、Clang 和 Swift 等基础设施的缔造者。当这样一位人物选择第三次做客播客,并宣称要解决 Python 的核心顽疾时,整个科技行业都应侧耳倾听。这场对话发生的背景,正是人工智能的“寒武纪大爆发”——模型能力飞速迭代,硬件创新也层出-不穷,而连接两者的软件栈却日益成为瓶颈,充满了复杂性与妥协。
Lattner 认为,AI 行业正深陷于“两个世界”的泥潭:研究员用 Python 探索,工程师用 C++/CUDA 部署,两者间的鸿沟造成了巨大的资源浪费和创新阻力。他与新公司 Modular 推出的 Mojo 语言及配套工具链,正是为了彻底终结这一局面。这场对话不仅是关于一门新语言的发布,更是一次对未来十年计算范式的深刻预判。它将直接影响所有 AI 开发者、CTO 和技术投资人关于技术选型、团队建设和未来布局的决策。Lattner 的方案雄心勃勃,但他也正试图挑战编程世界最强大的生态引力——他能否在不“背叛”Python 的前提下,完成对 Python 的“终极进化”?
2. 核心观点
Chris Lattner 的核心世界观是:AI 时代的根本矛盾,是模型创新与硬件创新的速度远远超过了中间软件栈的演化能力,导致了无法持续的“复杂性”爆炸。他断言,现有的 TensorFlow、PyTorch 等框架,连同其依赖的“Python + C++”双轨模式,是一种历史遗留的、充满妥协的架构,已成为行业发展的最大瓶颈。Lattner 的解法不是对现有体系修修补补,而是构建一个全新的、从底层硬件到顶层语法完全统一的“单世界”模型。这个世界观的争议性在于,它要求从根本上重塑行业的基础设施——这既是一项艰巨的技术挑战,更是一场与根深蒂固的生态惯性的豪赌。Lattner 认为,唯有如此,才能将 AI 的潜力从少数巨头的专属“武器”中解放出来,交到更广泛的开发者手中。
关键判断 1:AI 行业的“两个世界问题”是根本症结,必须从语言层面统一。 Lattner 指出,当前 AI 领域普遍存在研究(Python)与生产(C++/CUDA)的分裂。研究人员享受 Python 的灵活性和庞大生态,但其性能无法满足生产部署要求;而生产环境需要 C++ 等语言榨干硬件性能,但这又扼杀了迭代速度和易用性。团队间的“扔过墙”模式导致了数周甚至数月的延误。Mojo 的核心设计目标就是成为一个能覆盖从高层动态脚本到低层系统编程的单一语言。它的逻辑是:通过成为 Python 的“超集”,开发者可以无缝迁移现有代码和知识,然后在性能瓶颈处,逐步采用 Mojo 提供的静态类型、所有权机制和内存控制等 C++ 级别的特性,从而在一个统一的环境中完成整个开发周期。
关键判断 2:性能提升应是渐进式选项,而非初始门槛。
Python 的成功源于其极低的上手门槛和极高的表达力。Lattner 认为,任何试图“取代”Python 的尝试,如果以牺牲易用性为代价,都注定失败。Mojo 的哲学是“让 Python 用户拥有超能力”,而非强迫他们学习一套全新的范式。其底层逻辑是,代码可以从 100% 兼容 Python 的动态代码开始,此时它已经能因为编译执行而获得数倍于 CPython 解释器的性能。当需要极致性能时,开发者可以逐步引入 fn (严格函数)、类型标注、let (不可变变量) 等特性,并利用 Mojo 标准库提供的向量化、并行化、自动调优等工具,最终达到手写 C++/CUDA 的性能水平,甚至在 Jeremy Howard 的演示中实现了超过 35,000 倍的加速。
关键判断 3:硬件的未来是“古怪”且碎片化的,唯一出路是可编程的统一抽象层。 摩尔定律终结后,硬件发展的方向是专用化和异构化。CPU、GPU、TPU、NPU 等各种加速器层出不穷,它们的架构、内存模型、指令集各不相同。Lattner 认为这种“古怪”的趋势不可逆转,试图为每一种硬件手写优化内核的模式已经难以为继。Modular 平台的核心逻辑,就是提供一个可编程的、与硬件无关的抽象层。它通过 MLIR 等现代编译器技术,将高层的计算图(如 TensorFlow 或 PyTorch 模型)编译到任意目标硬件上。Mojo 语言则为这个抽象层提供了可编程的接口,让硬件专家和算法专家能在不修改编译器本身的情况下,为新硬件或新算法注入优化知识。这个体系的核心是化解硬件多样性带来的复杂性,让上层应用开发者不必关心底层细节。
关键判断 4:兼容 Python 生态是生存前提,必须不惜代价避免“Python 2 到 3”的灾难重演。 Lattner 多次强调,Mojo 并非要与 Python 决裂,而是要成为 Python 生态的一部分。他认为 Python 社区在 2->3 的迁移过程中遭受了巨大的痛苦,Mojo 必须避免重蹈覆辙。为此,Mojo 的策略是成为 Python 的严格超集,并提供与现有 CPython 生态的互操作性。在初期,Mojo 可以直接导入并使用任何现有的 Python 包(如 NumPy、Pandas),其底层是通过调用 CPython 解释器来实现的。这意味着用户可以立即利用整个 Python 生态,只在性能关键的“热点”代码上使用 Mojo 重写。这个逻辑链条是:以兼容性换取最低的采纳门槛,用显著的性能优势吸引用户,最终逐步将更多的核心库原生迁移到 Mojo 生态中。
这四个判断构成了一个完整的逻辑闭环:承认“两个世界”的问题,通过“渐进式增强”的语言设计来解决它,用“统一抽象层”应对未来的硬件碎片化,并以“完全兼容”作为切入现有生态的滩头阵地。
3. 批判与质疑
Lattner 构建的蓝图虽然宏大且逻辑自洽,但其成功依赖于几个极具挑战性的前提,并且在对话中某些风险被有意或无意地淡化了。
首先,“单一语言通吃一切”的假设本身值得商榷。 编程语言的设计充满了权衡(trade-off)。Python 的极致灵活性(如猴子补丁)与 C++ 的极致性能和控制力,可能在根本上是互斥的。Mojo 试图通过 def 和 fn 等语法区分来兼容两者,但这是否会引入新的复杂性,使得语言本身变得精神分裂?当一个项目混合了两种范式,调试和代码推理的难度可能会不降反升。Lattner 以 Swift 兼容 Objective-C 的成功为佐证,但 AI 生态的广度和深度远超当年的 iOS 生态。
其次,低估了生态系统的引力。 Lattner 正确地指出了兼容性的重要性,但生态系统不仅是代码库,更是数百万篇教程、Stack Overflow 问答、书籍、课程以及根植于开发者头脑中的思维模式。通过 CPython 桥接实现的“兼容”在性能和部署上终究是妥协,它解决了“能不能用”的问题,但无法提供“用得爽”的体验。Mojo 想要真正成功,必须激励社区用其重写核心库(如 NumPy),这是一个需要数年甚至十年才能看到结果的社会学过程,而非纯粹的技术问题。
再者,对性能优势的论证有“以点概面”的风险。 35,000 倍的加速来自一个理想的、计算密集型的 Mandelbrot 示例。在现实世界中,大部分 AI 应用的瓶颈是复杂的,混合了数据 I/O、内存带宽和异构设备间的通信。Mojo 在这些场景下的真实性能提升幅度,以及是否能轻易地被普通开发者实现,仍有待大规模实践的检验。
最后,一个悬而未决的问题是治理模式的张力。Lattner 在 LLVM 和 Swift 项目中展现了卓越的开源社区领导力。然而,Mojo 和 Modular 引擎由一家商业公司(Modular)主导。当公司的商业利益(例如,为特定付费客户优化)与社区的普遍需求发生冲突时,将如何决策?这种中心化的商业驱动模式与 Python 社区松散、去中心化的 PEP 治理模式截然不同,这可能成为未来发展的潜在摩擦点。
4. 行业视野
这场对话为我们提供了一个绝佳的坐标,来定位当前 AI 基础设施的演进位置。
它印证了“软件正在吞噬软件”的趋势。正如虚拟机和容器抽象了操作系统,Kubernetes 抽象了数据中心,Lattner 的 Modular 平台试图抽象整个异构计算硬件层。这不是一个孤立的想法,NVIDIA 的 CUDA 某种意义上也是一种抽象,但它是封闭的、专有的。Google 的 JAX、Meta 的 PyTorch 2.0(Triton 编译器)都在尝试解决类似问题,即如何将高层模型高效地编译到硬件上。Lattner 的方案更进一步,他认为不仅需要一个更好的编译器,更需要一门为这个编译器而生的、更具表达力的“用户态”语言(Mojo)。
它挑战了“Python 只是胶水语言”的根深蒂固共识。几十年来,行业的主流观点是 Python 负责编排和提供易用的 API,而真正的重活由底层的 C/C++/Fortran 库来完成。Mojo 试图打破这一共识,认为 Python 本身(或其超集)完全有能力成为一门高性能系统编程语言。这一点它与 Julia 语言的目标有相似之处,但 Lattner 吸收了 Julia 在生态兼容性上的教训,选择了更务实的“超集”路径。
这场对话也与一段重要的历史形成了呼应:C++ 与 C 的关系。Bjarne Stroustrup 当年创造 C++ 时,也面临类似抉择:是创造一门全新的语言,还是在 C 的基础上扩展?他选择了后者,这种对 C 的兼容性极大地促进了 C++ 的早期采纳。Lattner 显然在重复这一成功的“寄生”策略。他将 Mojo 定位为“更好的 Python”,就像 C++ 当初被定位为“带类的 C”一样,这是一种极其聪明的市场定位和生态渗透策略。
5. 启示与建议
这场对话首先挑战了一个核心假设:我们必须在“易用性”和“高性能”之间做出选择。 Lattner 坚信,通过更先进的编译器技术和语言设计,我们可以拥有一个平滑的、从易用到高性能的连续谱,而不是两个割裂的世界。
对开发者与产品经理:
- 将 Mojo 视为 C++ 的现代替代品,而非 Python 的直接替代品。 如果你的项目中存在大量 Python 与 C++ 混合编程的痛点(如复杂的构建系统、调试困难),Mojo 提供了一个极具吸引力的统一方案。可以考虑在下一个新项目中,用 Mojo 编写原本计划用 C++ 实现的性能关键模块。
- 关注 Modular 平台的硬件抽象能力,而不仅仅是 Mojo 语言。 真正的长期价值在于,它承诺将你的 AI 应用与底层硬件解耦。这意味着未来你可以更自由地选择性价比更高的芯片,而无需重写大量代码。
对投资人:
- 将 Modular 视为一家“AI 时代的 Red Hat 或 HashiCorp”,而非“下一个 Python”。 投资的核心逻辑是,随着 AI 硬件的碎片化,一个可靠的、跨平台的中间层将变得至关重要。Mojo 语言是其吸引开发者生态的“特洛伊木马”。
- 风险识别:密切关注社区动态和核心库的采纳进度。 Mojo 的技术再好,如果无法赢得 NumPy、SciPy、PyTorch/TensorFlow 社区核心贡献者的支持,它就只能停留在小众的高性能计算领域。真正的指数级增长信号,将是某个主流 AI 框架宣布提供一等的 Mojo 支持。
对创业者:
- 重新审视 AI 基础设施的创业机会。 如果 Lattner 的判断是正确的,那么围绕 Mojo 和 Modular 生态的“卖水”生意将大有可为:包括专门的 IDE 插件、调试与性能分析工具、Mojo 原生库的开发以及企业级支持与培训服务。
- 利用 Mojo/Modular 探索新的产品形态。 既然 Mojo 承诺将 AI 推理能力轻松部署到边缘设备上,这为需要低延迟、高隐私的端侧智能应用打开了新的大门。比如,可以开发过去因性能限制而无法在手机或嵌入式设备上实现的复杂模型。
最后,需要明确的是,Lattner 描述的“AI 基础设施的痛苦”是一个强信号,它已被行业广泛证实。而 Mojo/Modular 是解决这一痛苦的一种极具潜力的合理推断,但其最终能否成为行业标准,仍有待市场和时间的检验。在未来 1-2 年内,它更可能是一个“屠龙少年”的故事,而非既定的“新王”。
6. 金句摘录
-
“My belief of where computing goes, if you look out 10 years from now, is it’s not gonna get simpler. Physics isn’t going back to where we came from. It’s only gonna get weirder from here on out.”
- 中文意译:“我对于计算未来十年的信念是:它不会变得更简单。物理规律不会倒退回我们熟悉的样子,只会从现在开始变得越来越‘古怪’。”
- 语境:Lattner 在此解释为什么需要一个全新的、更具适应性的软件平台。他指出,随着摩尔定律的终结,硬件的专用化和异构化(他称之为“古怪”)是不可逆转的物理趋势,软件必须适应这个现实,而不是幻想回到过去那种通用 CPU 一统天下的简单时代。
-
“Our view is that Python is just not done yet.”
- 中文意译:“我们的观点是,Python 只是还没‘完成’而已。”
- 语境:在解释 Mojo 与 Python 的关系时,Lattner 用这句极其巧妙的话进行定位。他没有将 Mojo 描述为 Python 的“修复者”或“替代者”,而是将其定位成 Python 演化的自然延续。这既表达了对 Python 现有成就的尊重,又暗示了 Mojo 将为其补上缺失的“高性能”和“系统级编程”拼图。
-
“We’re not working forwards from making Python a little bit better. We’re working backwards from what is the limit of physics?”
- 中文意译:“我们不是从‘让 Python 好一点点’这个角度向前推进,而是从‘物理的极限在哪里’这个终点向后倒推。”
- 语境:当被问及为何不选择改进现有的 CPython 解释器时,Lattner 以此阐述他的第一性原理思维。他认为,许多项目只是在现有基础上做增量改进,而 Mojo 的出发点是直面硬件的终极潜力,然后反向设计一套能够完全释放这种潜力的语言和系统,这是一种根本性的范式转变。