Mojo 1.0编译器开源,Python++还缺什么

⭐ 设为星标 · 第一时间收到推送

此前开放的是库，这次开放的是语言栈

Mojo 不是到今天才有开源代码。标准库从 2024 年就开始接受社区贡献，随后 Modular 又开放了用 Mojo 编写的大量 CPU、GPU kernel，以及 MAX 的部分模型和服务代码。

但最关键的一层一直关着：编译器。你可以读标准库、改 kernel，却不能检查一段 Mojo 代码怎样被解析、做类型检查、降到 MLIR 和 LLVM，再变成 CPU 或 GPU 机器码。对个人试验影响不大，对准备长期押注一门语言的团队，这是硬门槛。

ModCon 2026 现场宣布 Mojo 开源，屏幕上的 Open Source 是这次发布的核心信息

官方说法： 8 月 18 日开放的是 Mojo 编译器、工具和构建语言所需的完整代码。仓库里的 KGEN 包含编译器库、命令行工具、LSP、调试与测试设施；mojo/stdlib 是标准库，max/kernels 则是此前已经开放的加速 kernel。

真正改变的，是团队能否长期押注

闭源时期，团队试用 Mojo 等于接受一个前提：编译器的安全、修复节奏、二进制供应和未来方向都由 Modular 控制。现在，团队可以固定自己的版本，审计编译过程，在官方来不及修时维护补丁，也可以为内部硬件或受限环境做分支。

GitHub 仓库已经能看到编译器、标准库、Bazel 构建规则和 MAX 组件处在同一棵代码树里。这个画面比“正式开源”四个字更有用：原来只能下载的核心，现在进入了团队自己的工程边界。

Modular 主仓库已经出现 KGEN、mojo、bazel 等完整语言栈目录

Apache-2.0 给了使用、修改、再分发和专利授权，LLVM exceptions 又放宽了编译产物中嵌入相关代码时的再分发义务，并处理与 GPLv2 组合时可能出现的条款冲突。对公司法务来说，这比“源码可见”更重要：你可以合法地维护私有分支和分发编译结果，不必把自己的应用一并开源。

仓库也给出了直接的源码构建路径：

./bazelw run --config=build-mojo //KGEN:mojo -- run hello.mojo

--config=build-mojo 会用本地源码构建编译器和标准库；测试标准库也能走同一套 Bazel 流程。它解决的是可复现和可验证，不代表门槛已经低到和 pip install 一样。Bazel 依赖、编译时间、缓存和 CI 仍然是团队要接住的工程成本。

官方仓库给出了用 Bazel 从源码构建 Mojo 的公开流程

还有一条容易被发布口号盖住的限制：本地构建的编译器目前不能构建 MAX targets，定制 MAX kernel 或模型仍需要预编译编译器。这里的“完整”指 Mojo 语言栈；Modular 商业平台仍有不同的许可证和构建边界。

后端可以改，不等于所有芯片已经自动支持

Mojo 一开始就瞄准了比“让 Python 代码跑快一点”更大的问题。它把高层语言逐步降到 MLIR/LLVM，并为 GPU 和其他加速器保留目标后端。当前官方支持 NVIDIA、AMD 和 Apple silicon，编译器源码里也能看到目标后端注册、NVVM、ROCDL 与 Metal AIR 等适配路径。

仓库事实： 后端注册、目标解析、LLVM lowering、调试信息和运行时接口现在都能被外部开发者检查和改动。硬件厂商不必等 Modular 发一个黑盒二进制，研究团队也能在自己的 fork 里接新指令、修 lowering 或做特殊加速器适配。

现实边界： 官方文档把硬件分成“持续测试”和“已知兼容”。截至 1.0，持续进 CI 的 GPU 主要是 NVIDIA B200、AMD MI355X 和 MI300X；更多 NVIDIA、AMD 卡以及 M1 到 M5 属于已知兼容。Windows 仍没有原生支持，只能通过 WSL。可移植的架构降低了接入新硬件的难度，但驱动、运行时、测试矩阵和性能调优并不会自己长出来。

许可证和治理要分开看。标准库、kernel、模型架构、文档和示例已经接受贡献，编译器与工具链暂时还不接外部 PR，官方目标是 2026 年底前开放。今天社区能自由 fork 和修改，却还不能共同决定上游编译器怎样演进。

“Python++”还缺哪些硬条件

Hacker News 上最直接的一类反馈是：“闭源时我可以忽略它，现在得认真看一眼了。”也有人马上追问 NumPy、SciPy 的对应生态，或者把 Windows 支持当成能否扩大采用面的门槛。围绕“不开编译器 PR 算不算真正开源”的争论也很典型：许可证允许 fork 与分发，和项目是否接受上游贡献，本来就是两件事。

这些评论不能代表整个社区，却准确暴露了 Mojo 1.0 的下一组问题。

Mojo 1.0 之后仍待补齐的四块：生态、工具、硬件覆盖和生产证据

Mojo 可以直接调用 NumPy，但那仍是在 CPython 解释器里执行，会带来语言边界和部署依赖；原生 NuMojo 等项目才是在补“Mojo 自己的科学计算生态”。官方路线图也很坦白：包管理、profiler、原生 Windows、更多硬件、async、模式匹配和更完整的内存安全仍在后面。

我的判断： 完整开源把 Mojo 从“有趣但不能托底的供应商语言”，推到了“可以审计、fork、移植并认真评估的候选项”。这对编译器团队、AI kernel 团队和硬件厂商是实质变化。对普通 Python 应用团队，今天还没有足够理由为了语法相似就整体迁移。