“編譯器之神”打造的AI編程語言——Mojo發布1.0.0b1：像Python一樣寫，像C++一樣跑

5月8日，AI基礎設施公司Modular正式發布了Mojo編程語言的首個Beta版本1.0.0b1。

這條消息在開發者社區引發了不小的波瀾——畢竟，“寫起來像Python，跑起來像C++”的承諾，已經讓人等了很久。

Modular成立于2022年，由前Google Brain主管Chris Lattner與Google Brain前副總裁Tim Davis聯合創立。Lattner是LLVM編譯器基礎設施、Clang C++編譯器以及Swift編程語言的創造者，被譽為“編譯器之神”。

Modular的核心使命是解決AI基礎設施的碎片化問題。當前AI開發面臨嚴峻挑戰：模型需要在不同硬件（NVIDIA、AMD、Intel、Apple Silicon）上運行，開發者被迫維護多套代碼；Python生態雖然易用但性能受限，C++高性能代碼又難以編寫和維護。Modular試圖通過統一的技術棧彌合這一鴻溝。

根據Modular官方博客披露，Mojo 1.0正式版預計將在2026年秋季發布，屆時將開放編譯器源碼并提供語言穩定性保證。當前Beta版本包含多項重要功能更新：安全閉包（Safe closures）引入新的捕獲語法、trait的條件一致性（Conditional conformance to traits）、以及對可變參數（variadics）的重大改進。

值得關注的是，Modular推出了TileTensor作為LayoutTensor的繼任者，進一步簡化高性能GPU內核的開發。TileTensor將內存布局作為張量本身的編譯時屬性，使得GPU內核所需的swizzles、strides和indexing操作可以由類型系統檢查，而非依賴人工維護。這一改進顯著降低了編寫高性能計算代碼的門檻。

與此同時，Mojo獲得了專屬網站mojolang.org，所有Mojo相關文檔已遷移至此，docs.modular.com則專注于MAX平臺的模型構建與部署文檔。

Mojo編程語言

為什么是Mojo？AI時代的性能焦慮

Mojo誕生于2022年底，定位非常明確：解決Python在AI和高性能計算場景下的性能瓶頸。Python憑借其簡潔的語法和龐大的生態，成為了AI開發的事實標準語言，但它的解釋執行特性也決定了其在計算密集型任務中的天花板。

Mojo的解法很直接——兼容Python語法，但引入編譯時類型檢查、內存安全和底層硬件訪問能力。開發者可以用熟悉的Python風格寫代碼，在需要性能的地方添加類型注解，編譯器就能將其優化到接近C++的執行效率。

1.0.0b1帶來了什么？

這次發布的穩定版標志著Mojo從實驗性語言邁向可用產品的關鍵一步。核心特性包括：

• AI原生設計：作為一門編譯型靜態語言，Mojo從底層就為現代AI系統的多樣化硬件（CPU、GPU、ASIC）優化，特別適合Agentic編程。

• GPU編程平民化：無需綁定特定廠商的庫，也無需單獨編譯內核代碼，開發者可以用同一門語言寫CPU和GPU代碼。官方示例中，一個GPU向量加法內核的代碼量與傳統CUDA方案相比大幅減少。

• Python無縫互操作：Mojo原生支持與Python的互調用。你可以逐步將Python項目中的性能瓶頸遷移到Mojo，而無需重寫整個代碼庫。Mojo代碼可以自然導入Python生態，也能被打包分發到Python項目中。

• 編譯時元編程：受Zig啟發的comptime機制讓開發者能在編譯期執行代碼、進行條件編譯和反射，實現零成本抽象。

相比此前偏向概念介紹的發布，Mojo v1.0.0b1帶來了大量觸及語言核心與系統編程層面的實質性變更——從關鍵字統一到指針非空設計，再到全平臺GPU硬件支持的擴展，標志著Mojo正在從「實驗性語言」向「生產可用」快速演進。

語言統一：fn被廢棄，def成為唯一函數關鍵字

最引人注目的語法變化是 fn關鍵字正式被標記為deprecated，并將在下一版本變為編譯錯誤。自v0.26.2啟動的def/fn統一工作至此完成：def成為Mojo唯一的標準函數聲明關鍵字，且繼承了原本fn的非拋異常語義。現有代碼中的fn會在編譯時收到警告，開發者需要盡早遷移。

與此同時，閉包機制也完成了統一。無狀態閉包會自動提升為頂層函數，可作為 FFI 回調傳遞；新的thin函數效應聲明了不攜帶捕獲狀態的純函數指針類型；而abi("C")效應則允許函數使用平臺C ABI，實現與C庫的安全互操作。捕獲列表語法{mut a, b, c^, read}也正式定型，支持按可變引用、不可變引用和移動語義顯式捕獲變量。

內存安全：UnsafePointer非空化，集合默認開啟邊界檢查

Mojo在內存安全方面邁出了重要一步。UnsafePointer 現在被設計為非空指針：默認的空構造函數和__bool__()方法已被廢棄，且不再遵循Defaultable和Boolabletrait。開發者需要用Optional[UnsafePointer[...]]來表達可空性。由于null地址被用作Optional的None niche，這種表達仍然是零開銷且FFI安全的。

標準庫集合也默認開啟了邊界檢查。所有CPU上的集合（List、Span、InlineArray、String等）在越界訪問時會直接報告用戶調用點，而非靜默崩潰。負索引也被徹底移除——x[-1]現在會觸發編譯期錯誤，必須改用x[len(x) - 1]。GPU 上的邊界檢查默認關閉以保證性能，但可通過-D ASSERT=all顯式開啟。

GPU編程：蘋果/AMD/英偉達全平臺覆蓋

本次更新在GPU支持上的投入尤為突出。Apple Metal方面，print()首次在Apple GPU上可用，動態線程組內存external_memory[]()獲得支持，Apple M5的MMA硬件矩陣乘加指令也通過apple_mma_load()等intrinsic暴露出來。AMD陣營新增了對MI250X加速卡的支持。英偉達方面則加入了對B300（sm_103a） 的識別與調度支持。

此外，GPU原語訪問器（thread_idx、block_idx、grid_dim等）的返回類型從UInt統一遷移為Int，這是Mojo向「所有尺寸和偏移量使用Int」方向邁出的關鍵一步。CPU端的DeviceContext(api="cpu")現在也變成了流有序執行上下文，支持enqueue_cpu_function()和enqueue_cpu_range()，為未來的NUMA感知CPU調度鋪平了道路。

字符串與反射：Unicode字形簇與編譯期類型細化

String和StringSlice新增了對UAX 字形簇（grapheme cluster） 的分段支持，能正確處理組合修飾符、emoji ZWJ序列、國旗emoji、韓語音節等多碼點簇。新增的graphemes()、count_graphemes()和[grapheme=...]切片語法讓文本處理更加精確。純ASCII 文本的count_graphemes()有大約10倍的加速。

類型系統方面，編譯器現在能基于where子句、comptime if和comptime assert進行類型細化。只要編譯期能證明某類型滿足某trait，就可以直接調用其trait方法，無需再使用trait_downcast。反射API也整合為統一的reflect[T]()入口，取代了原先分散的struct_field_*和get_type_name等自由函數。

工具鏈與生態

調試器體驗大幅改善：Variant和Optional在LLDB中現在直接顯示為Int(42) 或Some(value)，而非原始內部結構；標量類型直接顯示數值；UnsafePointer支持所有類型的正確顯示。LSP響應速度通過緩存和延遲解析得到了優化，長會話中的代碼補全從O(N2)降至攤還O(1)。Mojo包文件（.mojopkg）升級到格式v2，采用zstd壓縮的MLIR字節碼，顯著減小包體積。

開源路線圖：標準庫已開源，編譯器在路上

Modular在官網上明確表示，Mojo標準庫已完全開源在GitHub，歡迎社區貢獻。而編譯器本體計劃在2026年內開源。官方解釋稱，語言目前還很年輕，“一小群擁有共同愿景的工程師比社區驅動的方式推進得更快”。

Mojo的發展分為四個階段：

• Phase 0（已完成）：核心解析器、內存類型、函數、結構體等語言基礎。
• Phase 1（進行中）：高性能CPU+GPU編程，無縫擴展Python。
• Phase 2：系統級應用編程，引入保證的內存安全模型。
• Phase 3：動態面向對象編程，支持類、繼承和untyped變量，最大化Python兼容性。

目前1.0.0b1的發布意味著Phase 1已初見成效。對于既想保持Python開發效率、又不愿在性能上妥協的AI開發者來說，Mojo終于從一個漂亮的Demo變成了一個可以真正嘗試的選項。

參考來源

1. Mojo官網: https://mojolang.org/
2. GitHub: https://github.com/modular/modular

3. Mojo v1.0.0b1 發布說明：https://mojolang.org/releases/v1.0.0b1/

4. Mojo Roadmap: https://mojolang.org/docs/roadmap/