“编译器之神”打造的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(N²)降至摊还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/