編輯 | 聽雨

出品 | 51CTO技術棧（微信號：blog51cto）

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

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

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

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

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

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

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

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

你將了解到：

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

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

1.Chris 如何開始做LLVM

主持人：終于能見到你本人了！你做的工作對我影響很大。在 Adobe 時，我們全公司遷移到Swift，很多底層技術都建立在你寫的系統之上。2000 年初的編譯器世界是怎樣的？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Chris Lattner：

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

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

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

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

主持人：

等等，那時候你已經是蘋果的中層經理了吧？

Chris Lattner：

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

主持人：

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

Chris Lattner：

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

他們的反應是：“我們為什么要一門新語言？Objective-C 才讓iPhone 成功的啊！”

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

主持人：

從商業角度看，這其實挺合理的。

Chris Lattner：

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

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

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

主持人：

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

Chris Lattner：

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

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

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

主持人：

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

Chris Lattner：

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

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

主持人：

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

Chris Lattner：

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

主持人：

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

Chris Lattner：

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

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

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

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

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

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

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

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

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

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

4.Swift積累的技術債

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

Chris Lattner：

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

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

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

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

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

主持人：聽起來就像是語言內部也會積累“技術債”一樣。

Chris Lattner：

沒錯。語言也會有技術債，而且比產品更難還。

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

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

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

Chris Lattner：

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

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

5. 在 Google 和 Tesla 的 AI 工作中獲得的啟發

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

Chris Lattner：

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

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

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

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

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

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

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

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

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

6.Mojo 的起源故事：賭了一個兩層架構

主持人：

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

Chris Lattner：

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

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

主持人：

對，我前幾天看Anthropic 招聘，發現他們同時在招 CUDA 工程師、Google TPU 工程師、AWS Trainium 工程師……

Chris Lattner：

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

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

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

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

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

主持人：

對，這在Google 太典型了。

Chris Lattner：

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

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

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

主持人：

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

Chris Lattner：

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

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

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

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

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

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

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

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

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

主持人：

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

Chris Lattner：

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

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

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

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

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

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

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

主持人：

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

Chris Lattner：

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

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

主持人：

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

Chris Lattner：

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

主持人：

是啊，現在這種割裂確實很痛苦。

Chris Lattner：

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

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

主持人：

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

Chris Lattner：

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

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

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

主持人：

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

Chris Lattner：

我們內部確實有人這么說過。

主持人：

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

Chris Lattner：

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

參考鏈接：https://www.youtube.com/watch?v=Fxp3131i1yE&t=193s

本文轉載自??51CTO技術棧??，作者：聽雨