編輯 | 聽雨

“編譯器很酷，別讓任何人告訴你不是。”

這是LLVM之父 Chris Lattner 在最新一期《The Pragmatic Engineer》播客中說的話。

Chris Lattner，那個改變了編程史的人——他打造了LLVM，讓Apple、Google、ARM 全面棄用GCC；他用Swift 改寫了iOS 開發(fā)的語言規(guī)則；如今，他又用Mojo 試圖重塑AI 編程的未來。

但很少人知道，這一切都始于一個程序員在“夜晚與周末偷偷寫代碼”的副業(yè)。

在這期訪談里，Chris 親口講述了LLVM、Swift 與Mojo 的誕生故事，他如何秘密開發(fā)Swift超過一年；從大學研究項目，到Apple 內(nèi)部的技術(shù)革命，再到AI 時代的全新語言哲學。

Chris 認為，今天的 AI 行業(yè)正處在“GCC 之前的編譯器混亂時代”。各家廠商都在重復造輪子——沒有統(tǒng)一的底層標準，模型就得為每塊硬件重寫一遍。

他也提醒，為大語言模型重新造一門編程語言沒有意義。編程語言的“可讀性”比“易寫性”更重要。在一個由 AI 代理編寫代碼的世界里，最強大的語言將是那些表達力強、易于閱讀的語言。這或許也是 Python 長盛不衰的原因之一，也是 Mojo 的設計理念所在。

而在輝煌的履歷之外，Chris 最自豪的成就卻很樸實——Swift 普及后，有人會在街上攔住他，感謝他讓自己能用更易上手的語言成為 iOS 開發(fā)者。

你將了解到：

• Chris 如何在 Apple 內(nèi)部推動 LLVM，從邊緣項目變成核心基礎設施；
• 為什么 Swift 曾秘密開發(fā)了一年多，連公司高層都一無所知；
• Chris 在 Google 和 Tesla 時，對 AI 編程的第一手洞察；
• Mojo 誕生背后的故事——一門既像 Python 一樣易讀，又像 C 一樣高性能的新語言；
• Modular 團隊會選擇怎樣的工程師

小編幫大家精編了整期訪談實錄，信息量極大，從中你能看到一個頂級工程師的真實思考與選擇。

1.Chris 如何開始做LLVM

主持人：終于能見到你本人了！你做的工作對我影響很大。在 Adobe 時，我們?nèi)具w移到Swift，很多底層技術(shù)都建立在你寫的系統(tǒng)之上。2000 年初的編譯器世界是怎樣的？

Chris Lattner ：那時候我剛開始接觸 Linux，大概是90 年代中期。當時GCC 是主流編譯器——它算是把軟件世界“統(tǒng)一”起來的工具。在此之前，每個硬件廠商都要自己造編譯器，彼此完全不兼容，光編譯 C 語言都一團糟。

主持人：那是因為每家芯片的指令集都不同，所以要自己寫編譯器來映射，對吧？

Chris Lattner：沒錯。那時候芯片架構(gòu)百花齊放，各家都有自己的指令集。結(jié)果是軟件生態(tài)亂成一鍋粥。后來 GCC 出現(xiàn)，幫大家統(tǒng)一了標準。Linux 采用GCC，這推動了整個開源軟件生態(tài)的崛起。不過 GCC 架構(gòu)很老舊，不支持模塊化，也做不了JIT（即時編譯）或跨文件優(yōu)化。當時我在大學讀編譯原理，就想能不能造一個新的系統(tǒng)。于是開始了LLVM 項目，最初只是個“多架構(gòu)代碼生成系統(tǒng)”。說實話，一開始只是我自學編譯器的方式。

主持人：那后來開源的時候，大家反響怎么樣？

Chris Lattner ：剛開源時沒幾個人關心，最多兩三位同樣熱愛編譯器的“極客”加入。我們就這樣慢慢建立了一個小社區(qū)。

主持人：那 LLVM 相比GCC 最大的不同是什么？

Chris Lattner：一開始最大的不同是支持 JIT 編譯，也就是運行時生成機器碼。GCC 只能靜態(tài)編譯。另一個不同是LLVM 用 C++ 寫的，而 GCC 堅持用 C，這在當時非常有爭議。

主持人：那你后來是怎么加入 Apple 的？

Chris Lattner：我畢業(yè)找工作時，想繼續(xù)做編譯器。剛好 Apple 的工程師在研究把 LLVM 接入 PowerPC，就邀請我加入。Apple 當時對 GCC 很不滿，覺得太慢、太舊了。他們讓我全職開發(fā) LLVM，剛開始只給了我一個同事。主管還說：“如果一年后 LLVM 還沒在產(chǎn)品中用上，我們就讓你做別的。”于是我開始找實際落地的機會，第一個落地是在 OpenGL 的JIT 圖形編譯上。那是 LLVM 第一次為Apple 帶來實際價值。

主持人：所以是從一個小項目開始，一步步擴展？

Chris Lattner：對，花了五年。我們后來重寫了 C++ 和Objective-C 前端，也做了調(diào)試器。到 2010 年，Apple 發(fā)布首款 64 位 iPhone，這一切都離不開 LLVM。那時全世界都驚呆了。

主持人：那你是怎么說服 Apple 這么封閉的公司去開源Clang 和Swift 的？

Chris Lattner：Clang 是最容易的，因為我們根本沒走審批流程，直接開了。Swift 才是真正難的那個。

2.Swift的誕生故事：半夜和周末偷偷寫代碼

主持人：那 Swift 是怎么開始的？

Chris Lattner：

Swift 是我2010 年左右開始在“秘密狀態(tài)”下做的——沒人知道，只有晚上和周末寫。我當時已經(jīng)重寫完C++/Objective-C 工具鏈，心里就想：C++ 太復雜了，我們能不能做得更好？于是我研究了幾十種語言，從 Java 到 OCaml、Haskell、TypeScript、Go……試圖取長補短。Swift 的目標是：讓編程既簡單又能擴展，從腳本級別一直覆蓋到底層系統(tǒng)開發(fā)。

Objective-C 當時是“兩種語言的混合體”，C 負責性能，小對象系統(tǒng)來自 Smalltalk。Swift 就是要把這兩種力量融合為一，既高效又安全，還更容易教學。

主持人：你差不多在 2010 年左右開始業(yè)余做Swift 的實驗項目吧？那為什么要到2014 年才發(fā)布第一個版本？

Chris Lattner：事實證明，做編程語言真的不容易——大概需要四年時間。讓我簡單梳理一下整個過程。最開始的一年半，真的是我一個人在做。對，就是晚上和周末偷偷寫代碼。白天我有正式工作，還要管理一個大團隊，事情非常多。

主持人：

等等，那時候你已經(jīng)是蘋果的中層經(jīng)理了吧？

Chris Lattner：

對，那時我管著一個 40 人的團隊，做很多非常有趣的項目。

主持人：

看來你真的很擅長“同時處理好幾件事”。

Chris Lattner：

確實是我的熱情項目。我編程能力也不錯，這確實幫了忙。一年半之后，我決定告訴公司管理層：“我在做一個新語言項目，你們怎么看？”

他們的反應是：“我們?yōu)槭裁匆婚T新語言？Objective-C 才讓iPhone 成功的啊！”

我就說：“那我能不能找一兩個人幫我一起做一點？”他們說：“好吧，你可以告訴他們這件事，但我們不會給你資源。”不過我當時在公司還算受尊重，所以他們給了我比一般人更多的自由空間。于是我繼續(xù)做 demo。到了第三年，大多數(shù)反饋都是：“如果你不喜歡Objective-C，那就去讓Objective-C 變得更好。”

主持人：

從商業(yè)角度看，這其實挺合理的。

Chris Lattner：

是的，完全合理。Objective-C 是整個生態(tài)的基石，風險低，還能延長現(xiàn)有投資的價值。于是我開始了“雙線推進”：一邊研究 Swift，一邊改進 Objective-C。

我意識到 Objective-C 缺乏內(nèi)存安全機制，retain / release 全靠手動，簡直是噩夢。于是我們發(fā)明了ARC（自動引用計數(shù)），讓內(nèi)存管理自動化、更安全，也更容易教學。接著我們又做了Modules（模塊系統(tǒng)）、Literals（字面量語法） 等功能。這些特性實際上是在一步步讓 Objective-C 的開發(fā)體驗靠近 Swift，這樣當 Swift 發(fā)布時，開發(fā)者不會覺得太突兀。

當然，這依然是一次巨大飛躍。與此同時，我的團隊已經(jīng)擴展到約 250 人，負責整個 Xcode 和開發(fā)者工具部門。

主持人：

所以那時你白天管 Xcode 團隊，晚上繼續(xù)做Swift？

Chris Lattner：

是的。你現(xiàn)在還能在 GitHub 上看到那幾年我的提交記錄。

到了某次高層評審會議，我提出希望讓 Swift 成為部門的重點項目。當時 Swift 還無法與 iOS SDK 通信，沒有對象系統(tǒng)，也沒有任何基于它的應用。最后一年我們瘋狂趕工：完善語言、整合調(diào)試器、代碼格式化、Xcode 插件、與 iOS SDK 集成……那真的是一場硬仗。

這些努力，才讓 Swift 在四年后終于能發(fā)布。回頭看，我們犯了個錯誤：我們把它叫1.0。

主持人：

我正想問這個。我當時用的是 1.2 版，但1.0 出來的時候問題確實很多——Xcode 沒有重構(gòu)功能，調(diào)試也很痛苦。為什么還是選擇那時發(fā)布？

Chris Lattner：

因為蘋果不會發(fā)布0.5 版，如果要正式發(fā)布，就得叫 1.0。但我們也知道，必須讓開發(fā)者早點用上、獲得反饋。當時整個蘋果公司知道 Swift 的人不超過250 個——主要是我團隊和少數(shù)高層。我們很清楚：你不可能在閉門 NDA 下做出一門好語言。必須放出去、讓用戶真實使用。

所以我學到的教訓是：“不要叫 1.0，除非它真的成熟、有足夠使用經(jīng)驗支撐。”這些經(jīng)驗，我們現(xiàn)在在 Mojo 上都銘記于心。

主持人：

我記得那時候開發(fā)者又激動又抓狂。2014 年iPhone 生態(tài)太火了，大家都想趕上這波浪潮。

Chris Lattner：

沒錯，我們當時對開發(fā)者說得很清楚：“你們可以用 Swift 開發(fā)并上傳到 App Store，但請注意，我們會頻繁改動語言、可能會打斷你的源代碼。”我們承諾會提供遷移支持，但希望大家理解——語言必須在實踐中迭代。我很慶幸我們做了這件事。

主持人：

是的，雖然當時很多人抱怨，但大家也知道蘋果是認真的。很多公司，比如 Uber，在 2016 年左右做出了大膽決定：全面用 Swift 重寫App。那是一次風險巨大的遷移。團隊內(nèi)部調(diào)查幾乎 50% 支持 Objective-C、50% 支持 Swift，意見非常分裂。沒人知道最終是誰拍板的，但他們賭對了。后來回頭看，這確實是正確的選擇。

Chris Lattner：

是的，我也聽說了很多那時候的爭論。有的開發(fā)者激動地擁抱新語言；也有的專家憤怒地說：“Objective-C 好好的，干嘛改？”他們搖著拳頭說：“我永遠不會用那玩意！”

想想看——如果你是Objective-C 的專家，干了五年、十年，掌握了所有技巧和奇技淫巧，是別人遇到bug 時求助的對象。突然 Swift 出來了，你的經(jīng)驗一下子被清零，變成新手。你當然不想接受新語言，你想繼續(xù)當“老語言的王者”。所以除非有足夠好的理由，否則沒人愿意放棄舊系統(tǒng)。

Swift的普及就是個典型的技術(shù)擴散曲線——最早是早期采用者：喜歡嘗鮮、追求新技術(shù)的人；然后才是主流用戶；再后來是那些必須“被拖著走”的人。你必須等到一個關鍵轉(zhuǎn)折點出現(xiàn)，比如后來 SwiftUI 的發(fā)布，才會讓更多保守開發(fā)者徹底轉(zhuǎn)向。

從更宏觀的角度看，這其實就是技術(shù)采納的 S 型曲線。一開始是少數(shù)人嘗試，隨后快速擴散，最后才慢慢進入穩(wěn)定期。Swift也完全符合這條曲線。

3.Chris 的驕傲：讓更多人能寫代碼

主持人：我們等會會聊到 AI，但我覺得你剛剛說的那些，其實正在重演。

Chris Lattner：沒錯，這完全是人類行為的共性。而在我整段旅程里，有一件事讓我特別自豪。我從 2010 年開始做Swift 時，其實只是一個業(yè)余玩具項目。那時候我只是模糊地覺得，“我們能不能做出一門比C++ 和 Objective-C 更好、更易用的語言？”但我完全不知道它最終會走到哪一步。

Swift 發(fā)布后，常常有開發(fā)者在街上攔住我，對我說：“謝謝你，Chris。多虧了 Swift，還有背后那支團隊，我才能成為一名 App開發(fā)者。以前我嘗試用Objective-C 寫 App，但我永遠搞不懂指針和中括號，程序總是崩潰，我甚至覺得自己不夠聰明，不適合做移動開發(fā)。可是有了Swift，我終于能寫出應用。現(xiàn)在我不僅是公司里的iOS 專家，還憑這個在職業(yè)上實現(xiàn)了成長。”

這些故事讓我深受觸動。因為他們不是天才，而是普通開發(fā)者。Swift讓他們有機會進入一個原本被門檻擋住的世界。

而這，正是我熱愛這份工作的原因：我相信程序員的力量，相信人類的創(chuàng)造潛能。軟件的偉大之處在于：它讓人類能把想象變成現(xiàn)實。能幫助別人“解鎖能力”的技術(shù)，是我永遠熱愛的領域。

4.Swift積累的技術(shù)債

主持人：現(xiàn)在回頭看，Swift 已經(jīng)有自己的生命了。你從零創(chuàng)建它、帶領它成長，如今它在蘋果體系中繼續(xù)演化。你怎么看 Swift 今天的發(fā)展？哪些地方讓你驕傲？又有哪些地方，你覺得如果你還在蘋果，也許會做得不一樣？

Chris Lattner：

這是個很難的問題。我不敢說如果我留在蘋果，它會更好或更差。但我能講講我自己早期的一些錯誤。

老實說，當年做 Swift 的時候，我其實根本不知道自己在干什么。我以前寫過 C++ 編譯器，有標準規(guī)范可遵循；但 Swift 是我第一次從零設計語言。

很多設計是新穎的，比如類型推斷和表達式檢查的算法，但我不是數(shù)學出身，很多問題其實可以更優(yōu)雅地解決——只是我沒看出來。比如 Swift 有些復雜表達式的類型檢查會極度耗時，這就是我設計失誤的結(jié)果。

另一個錯誤是：我們太快地加入太多特性，超出了架構(gòu)能承受的范圍。尤其是 Swift 1 時代，編譯器內(nèi)部結(jié)構(gòu)與語言設計并沒完全對齊。結(jié)果就是：很多功能“80% 可用”，但拼在一起并不順暢。隨著新特性一層層疊加，復雜性不斷膨脹。

其實 C++ 也有同樣的問題。但 Swift 因為追求快速落地，沒花夠精力去重構(gòu)核心、重新打磨底層設計。我們一心想讓開發(fā)者盡快寫出 App，于是不斷往語言里塞新東西，最后就形成了今天人們常調(diào)侃的“Swift 關鍵字太多”現(xiàn)象。所以復雜性不是一朝一夕，而是早期架構(gòu)沒對齊導致的連鎖反應。

主持人：聽起來就像是語言內(nèi)部也會積累“技術(shù)債”一樣。

Chris Lattner：

沒錯。語言也會有技術(shù)債，而且比產(chǎn)品更難還。

舉個例子，C++ 里 int 和float 是硬編碼在語言里的；但復數(shù)（complex）不是，它是模板庫實現(xiàn)的。為什么？因為歷史遺留。C++來自C，而模板是后來才加的，所以沒法回頭修正。結(jié)果就造成今天的復雜體系。

Swift 在這方面就做得更干凈：Int、Float 等基本類型都在標準庫中定義，而非硬編碼在語言層。這讓語言內(nèi)部更一致、更靈活。但這也說明——老語言的歷史包袱很重，新語言才能重來。

主持人:我之前采訪 Steve McConnell 時，他說微軟最好的工程師會把同一個程序重寫三次：第一次花一周半，第二次三天，第三次一天。Python也是第三次迭代后才定型。聽起來你在 Swift 里也經(jīng)歷了類似的過程——看到 C++ 的錯誤，但又發(fā)現(xiàn)了新的錯誤。

Chris Lattner：

確實如此。我相信人生中總會犯錯，但關鍵是：要學會只犯新的錯誤。從過去吸取教訓，不要重復老錯。

Swift 的一個好決定是——我們敢于打破兼容性。Swift 1 → Swift 2 → Swift 3 的過程中，我們主動“破壞”語言，為了修正設計缺陷。到 Swift 3 才真正宣布穩(wěn)定。這很痛苦，但很值得。想象一下如果今天我們還停留在 Swift 1……那簡直是災難。

5. 在 Google 和 Tesla 的 AI 工作中獲得的啟發(fā)

主持人：我們來聊聊你離開蘋果后的經(jīng)歷。你去過 Tesla、Google Brain、SiFive，這些地方都很傳奇。你在那學到了什么？這些經(jīng)歷又怎么引領你走向現(xiàn)在的Mojo？

Chris Lattner：

在蘋果，我研究 CPU、GPU，做編譯器、做 Xcode、做 OpenCL，學到了軟件與硬件邊界的全部細節(jié)。

到了2016 年，我注意到 iPhone 的相冊可以自動識別貓狗。我當時想：“我做了十幾年開發(fā)工具，居然不知道這是怎么實現(xiàn)的？”于是我掉進了一個新世界——AI。

我加入 Tesla 做自動駕駛軟件，第一次真正接觸了 Caffe、TensorFlow 等框架。那時我發(fā)現(xiàn)：這些工具雖然強大，但還遠遠不夠好。它們沒有一個像 LLVM 那樣的統(tǒng)一底層。

于是我加入 Google，領導TensorFlow 的底層系統(tǒng)：包括 CPU、GPU、TPU，以及各種內(nèi)部定制芯片的編譯層。尤其是 TPU 平臺——那是當時全球最前沿的 AI 硬件。

我從那段經(jīng)歷學到兩點：第一，AI 軟件真的很難寫。第二，整個 AI 世界都被NVIDIA 的CUDA 體系所“鎖定”。CUDA 很成熟，但已經(jīng)20 年了。我們需要新的技術(shù)棧。

于是我開發(fā)了MLIR（多層中間表示） ，一個為 AI 芯片設計的“新一代LLVM”。它成為了 Google、OpenAI、Meta、AMD、NVIDIA、英特爾等的共同底座。

后來我去了SiFive，那是一家做 RISC-V 芯片的公司。我想：“我這一輩子都在做軟件，不如去硬件那一邊看看。”結(jié)果我學到了芯片設計、驗證、IP 授權(quán)等整個硬件世界。我們甚至打算自己做一款 AI 芯片。

但問題又出現(xiàn)了：“軟件呢？AI 芯片的通用軟件棧在哪里？”答案是：根本沒有。沒有一個統(tǒng)一的基礎設施，能讓芯片廠商“即插即用”地支持AI 計算。于是我和當時在 Google 的同事一起創(chuàng)辦了Modular。

我們的目標是：“為 AI 世界打造一個像 LLVM 之于 CPU 那樣的底層軟件基礎。”Mojo 語言就是在這種背景下誕生的。它的使命是讓 AI 開發(fā)者不用再被 CUDA 或底層硬件束縛，而是能像寫 Python 一樣高效，又像C++ 一樣快。

6.Mojo 的起源故事：賭了一個兩層架構(gòu)

主持人：

對于我們這些只是普通的軟件工程師——不是做AI 底層的，只是調(diào)用模型 API、使用推理接口的人來說，如果今天我們真的想構(gòu)建AI 應用、直接在GPU 上運行，不管是NVIDIA、AMD 還是Google 的GPU，我們該用什么軟件？當你創(chuàng)立Modular 時，當時業(yè)界的“現(xiàn)狀”是什么？ 

Chris Lattner：

在GCC 出現(xiàn)之前，每個芯片廠商都得自己造編譯器——AI 現(xiàn)在的狀況就是這樣。每個硬件廠商都得自己從頭做一整套“垂直棧”（vertical stack），因為沒有任何一個通用的、可插拔的標準基礎設施。

比如我在Google 時，我們造了XLA，專門給TPU 用的，就像 NVIDIA 有 CUDA 一樣。Apple有Metal 和MLX 全棧，AMD 有 ROCm，每家公司都要造自己的一整套系統(tǒng)，而且它們之間幾乎沒有共享代碼。

主持人：

對，我前幾天看Anthropic 招聘，發(fā)現(xiàn)他們同時在招 CUDA 工程師、Google TPU 工程師、AWS Trainium 工程師……

Chris Lattner：

沒錯，他們得把同一個模型重寫三遍。同樣的算法，得針對三種不同的硬件各寫一套。而且這種模式問題多得驚人。

Anthropic 前陣子發(fā)過一篇很棒的工程博客，講得非常真實，他們發(fā)現(xiàn)：同一個模型被三支團隊并行維護三份實現(xiàn)，結(jié)果bug 層出不窮，性能不一致，線上質(zhì)量參差不齊，甚至導致宕機。因為三套系統(tǒng)永遠不同步。

所以Modular 的出發(fā)點很簡單：我已經(jīng)在Google、TPU、SiFive 的硬件生態(tài)里見識過所有這些痛點。那是大約四年前（2021 年左右），當時AI 硬件生態(tài)開始爆發(fā)，但還非常不成熟。我手上已經(jīng)積累了十幾年的編譯器和硬件經(jīng)驗，于是我環(huán)顧四周：有PyTorch、有 ONNX Runtime、還有無數(shù)別的框架——但沒有一個人愿意真正解決根本性的問題。

大家都在重復我在Google 時遇到的那套困局，我很喜歡在Google 的那段經(jīng)歷，學到了很多，團隊也非常優(yōu)秀。但我們的問題是這樣的：每年都有新芯片出來，每年都得“救火”，讓新芯片跑起來。而與此同時，所有的產(chǎn)品團隊（Search、Ads、YouTube）還在用舊芯片、舊棧。

所以最優(yōu)秀的人都被派去救生產(chǎn)環(huán)境的火，根本沒帶寬去做深層創(chuàng)新。尤其是任何超過6 或12 個月才能見效的項目，基本都被績效周期壓垮。

主持人：

對，這在Google 太典型了。

Chris Lattner：

結(jié)果就是：我們做了很多小改進、微優(yōu)化，也確實有巨大創(chuàng)新（模型結(jié)構(gòu)、研究突破），但底層系統(tǒng)仍然極其脆弱、難以擴展。它不可復用、不可組合，也沒法快速支持新硬件。

我在編譯器、語言、DevTools 上已經(jīng)干了很久，于是我決定：這次必須從根上解決問題。但這事不是三個人周末能干完的，它需要數(shù)年時間、需要非常頂級的團隊。

你想想——CUDA 已經(jīng)發(fā)展了 20 年，上千工程師在維護。AI芯片極其復雜，算法迭代飛快。所以唯一能做這件事的方式，就是成立一家VC 支持的公司，去從Apple、NVIDIA、Meta、Google 等公司挖出頂尖工程師，把他們聚到一起重新打造AI 的底層架構(gòu)。這就是Modular 的誕生。

主持人：

你之前在另一個播客里提到過一句話我很有印象：你說內(nèi)核工程師、編譯器工程師、AI 工程師“腦回路完全不同”，幾乎沒什么交集。但其實他們又必須一起工作，對吧？能講講這種差異嗎？

Chris Lattner：

當然。讓我先講Modular 技術(shù)路線的“頓悟時刻”。2021 年，那時TensorFlow 和PyTorch 已經(jīng)差不多快十歲了——它們都誕生于2015 年。在AI 的時間尺度里，這已經(jīng)是“史前時代”了。

它們的核心思路是：用CUDA、Intel MKL 寫好底層內(nèi)核（kernel），再在上層用Python 封裝API。但問題是——太容易寫kernel 了！

大家各自寫了成千上萬個內(nèi)核函數(shù)，結(jié)果這些內(nèi)核完全無法移植。每次上新硬件，就得重寫幾千個kernel。

后來我們在Google 的TPU 項目里有了一個突破：“能不能用編譯器自動生成這些 kernel？”結(jié)果非常好。編譯器可以在運行時自動合并、生成、優(yōu)化kernel，比如實現(xiàn)“auto fusion”（算子融合），性能還更強。那真是一段很有趣的經(jīng)歷。

但問題是——AI 迭代太快了，編譯器工程師又太少。當出現(xiàn)新的算法，比如Flash Attention、新稀疏結(jié)構(gòu)、新浮點格式時，編譯器團隊往往跟不上節(jié)奏。這直接導致了Google 內(nèi)部GPU 平臺的落后，尤其是在生成式AI（GenAI） 崛起之后，舊的編譯器方案基本被淘汰。

所以我得出結(jié)論：我們需要的是一種完全可編程的方式，要有對硬件的完全控制，不能再依賴那種“聰明到不可控”的編譯器。我不想再看到那種“做到一半就得換系統(tǒng)”的局面。我想要一個能從底層擴展到應用層的統(tǒng)一體系。

于是我們賭了一個兩層架構(gòu)：底層是Mojo 編程語言，上層是AI 模塊棧。大家都知道：做新語言幾乎注定失敗。但我有點“前科”還不錯（Swift）。

Mojo 的核心理念是：把編譯器的強大能力交還給開發(fā)者。傳統(tǒng)編譯器太“聰明”——它想幫你自動優(yōu)化，但又經(jīng)常出錯、不可預測。而Mojo 讓你能直接控制這些行為。這樣，即使你不是編譯器專家，也能寫出編譯器級的高性能代碼。

這打破了“人才瓶頸”：你不必是LLVM 黑客，也能用 Mojo 寫出高性能、可組合的 AI 系統(tǒng)。

主持人：

那Mojo 是怎么做到的？你怎么能既保持性能、又不被編譯器黑箱化？

Chris Lattner：

這是我整個職業(yè)生涯的延續(xù)。我在編譯器領域已經(jīng)20 年了，犯過無數(shù)錯。我逐漸意識到：傳統(tǒng)編譯器想做得太“智能”了。編譯器工程師喜歡展示優(yōu)化實力——讓某個循環(huán)快 2 倍、快10 倍。但那種做法會讓語言本身變得不可預測。

舉個例子：假如編譯器自動幫你“向量化”循環(huán)（SIMD），只要代碼稍微改動一點（比如修個bug），那個優(yōu)化就失效——性能突然慢 4 倍。然后你根本不知道為什么，調(diào)不動、也沒人修，這就是所謂的“抽象泄漏（leaky abstraction）”。

在AI 世界，GPU 太貴了。你如果達不到峰值性能，用戶立刻會換平臺。尤其是大模型實驗室，他們需要榨干每一份性能。所以我們選擇了一個完全不同的方向：讓編譯器更簡單、更現(xiàn)代，但更可預測、更可控。你可以顯式調(diào)用優(yōu)化，而不是依賴黑箱。比如你想啟用向量化，就直接寫@vectorize，不用再“祈禱編譯器看懂”。

更重要的是，Mojo 有一個非常強大的編譯期元編程系統(tǒng)，靈感來自Zig（并且我們在此基礎上改進了它）。

它讓你能在編譯階段執(zhí)行代碼、生成代碼。換句話說，你可以寫一個函數(shù)在編譯時展開成上千行優(yōu)化后的機器級邏輯。這樣，你能獲得編譯器級的性能，但只用寫普通的高層代碼。

更妙的是，Mojo 把運行時與編譯時語言統(tǒng)一成一個體系，不像C++ 那樣分裂（模板系統(tǒng)幾乎是另一門語言）。這意味著：只有一套語法需要學習；可以調(diào)試、可以運行、可以組合；能構(gòu)造真正“通用但高性能”的抽象。

7.Modular 會招聘怎樣的工程師

主持人：

你們的團隊現(xiàn)在多大了？你們在招什么樣的人？是主要找編譯器工程師，還是更多偏向機器學習的工程師？

Chris Lattner：

我們現(xiàn)在團隊大概一百多人吧。其實 Modular 是一半編譯器、一半 AI 的組合。我們最早在做的事，就是把這兩個世界融合在一起。編譯器工程師通常來自 Apple、NVIDIA、Google、Intel 這樣的硬件公司，他們非常懂硬件性能。而 AI 工程師往往來自 OpenAI、DeepMind、Meta、Anthropic，他們更懂模型層、推理層。我們希望讓他們可以在同一張桌子上工作，不再像以前那樣完全脫節(jié)。

我們團隊文化挺特別的。我們喜歡“系統(tǒng)思維”——不是盯著某個小模塊，而是從算法到硬件、從語言到底層編譯整個鏈條都去理解。我們常說，AI 模型只是軟件堆棧的一層，而不是全部。

主持人：

這聽起來就像是想要“重寫”整個 AI 基礎設施？

Chris Lattner：

你可以這么說。其實我們不是真的要“重寫”，而是要重建那些原本就該互通的層。就像當年 LLVM 讓所有語言都能共用編譯后端一樣，我們希望Modular 也能成為 AI 領域的LLVM。今天，每個硬件、每個模型框架、每個推理引擎都得自己寫一整套代碼——這不該是這樣。

主持人：

是啊，現(xiàn)在這種割裂確實很痛苦。

Chris Lattner：

沒錯，尤其是對于創(chuàng)業(yè)公司、小團隊來說。你想支持GPU，就要寫一遍；想上TPU，再寫一遍；AMD又一遍。太浪費精力。我們希望構(gòu)建一個統(tǒng)一的“編譯層”，能一次編譯、到處運行。

從這個意義上講，Mojo 只是入口。真正的愿景，是 Modular 平臺能讓每個人——無論是科研人員、AI 開發(fā)者，還是硬件廠商——都能在一個共享基礎上協(xié)作。這也是為什么我們叫它“Modular”，模塊化的未來。

主持人：

太棒了。你知道嗎，我第一次看到 Mojo 發(fā)布時，心里真的有種“這可能是 AI 時代的Python 2.0”的感覺。

Chris Lattner：

我們確實聽到過很多類似的評論。其實我們一點都不想取代Python，反而是希望延續(xù) Python 的精神——讓計算更開放、更易用。Python 是世界上最有生命力的語言之一，但它是在性能不是核心矛盾的時代誕生的。

而現(xiàn)在，我們進入了“算力即貨幣”的時代，效率和可移植性變得前所未有的重要。

Mojo 想做的事，就是讓開發(fā)者既能擁有Python 的快樂，又能獲得接近底層 C/C++的性能。

主持人：

這句話可以當標語用了——“像 Python 一樣快樂，像 C 一樣快”。

Chris Lattner：

我們內(nèi)部確實有人這么說過。

主持人：

謝謝你今天的分享，太精彩了。

Chris Lattner：

非常感謝邀請。也歡迎大家來modular.com看看，親自試試Mojo，加入社區(qū)。