马斯克一句“真男人自己管内存”，把 Rust 程序员惹急了！

本文永久链接 – https://tonybai.com/2026/11/11/musk-rust-c-ai-inference-stack

大家好，我是Tony Bai。

【导读】

马斯克最近在 X 上的一番言论，让 C 与 Rust 之间的老话题再次升温。为了 Grok 4.8，xAI 据称放弃了 JAX/SGLang，转而使用 C/C++ 从头重写强化学习和推理技术栈。当有人问为什么不用 Rust 时，Musk 回答：“真男人自己管理内存。”

这究竟是一次技术路线选择，还是一场程序员之间的语言信仰之争？在 AI 基础设施越来越依赖极致性能、内存效率和硬件控制能力的今天，C、C++ 和 Rust 的竞争，正在呈现出一些值得重新审视的变化。

【文章要点】

马斯克语出惊人引爆论战：为了 Grok 4.8 的极致性能，xAI 据称放弃了 JAX 与 SGLang，从头使用 C/C++ 重写了整个强化学习（RL）与推理基础设施，并以“真男人自己管内存”正面回应为何不用 Rust；
AI 基础设施为何重拾 C/C++：现代大模型长上下文推理面临严峻的 KV Cache 显存碎片、高频多卡通信与请求调度瓶颈，直接访问裸金属硬件与精准控制内存布局成为压榨经济性的关键抓手；
两门语言的哲学分水岭：C 语言主张将无限的自由与控制权交给程序员，代价是开发者必须独自承担内存泄漏、UAF 等安全责任；Rust 则通过所有权、借用与生命周期将安全保证前置到编译期；
性能并非绝对鸿沟：Rust 具备零成本抽象能力，性能上限并不天然逊色于 C；C 语言的真正壁垒在于数十年积淀的底层生态、工具链惯性与极为成熟的硬件 ABI 集成；
AI 时代重塑语言竞争：AI Coding Agent 正在大幅降低跨语言重写与机制理解的门槛，未来的软件架构不再由单一语言包打天下，而是根据具体场景将 C/C++（极致硬件）、Rust（安全底层）、Go（网络基础设施）与 Python（数据生态）有机结合。

【Go, Rust & AI 精进营】一年仅一次 · 双 11 限时特惠，长按下方图片扫码，直降入营：

一场由 Musk 引爆的语言之争

2026 年 11 月 11 日，Elon Musk 在 X 上发布了一条关于 Grok 4.8 的消息。

事情的起因，是一位 X 用户询问：Grok 4.8 什么时候可以发布？

Musk 给出的回答透露了一个相当有意思的工程细节：

We have dumped JAX/SGLang and rewritten the entire RL and inference stack from scratch in C/C++, which took some extra time.

翻译过来就是：

我们已经放弃了 JAX/SGLang，从头使用 C/C++ 重写了整个强化学习和推理技术栈，这花费了额外的时间。

他还透露，预训练已经完成，团队对 SFT（监督微调）数据进行了大量清理，现在 Grok 4.8 已经进入 RL 阶段，评估工作也开始启动。

这条消息本身已经足够引人关注。

JAX 是现代机器学习领域的重要计算框架，SGLang 则是面向大语言模型推理的重要系统。xAI 决定放弃这套技术组合，转而用 C/C++ 从头重写整个 RL 和 Inference 技术栈，这显然不是一个轻松的工程决定。

随后，一位 X 用户提出了一个很直接的问题：

Was it written in Rust? Why did you rewrite it in C/C++?

既然要重写底层技术栈，为什么不选择 Rust？

Musk 的回答只有一句：

Real men manage their own memory.

“真正的男人，自己管理内存。”

这句话迅速点燃了 Rust 社区。

随后，Musk 又补充了一条：

So easy to trigger Rust programmers 😂

紧接着，他给出了相对正式的技术解释：

Rust is a good language, but C is what you use for optimal performance on bare metal. With great power comes great responsibility.

Rust 是一门很好的语言，但如果你想在裸金属上获得最佳性能，C 才是你的选择。能力越大，责任越大。

一场原本关于 Grok 4.8 技术栈的讨论，就这样变成了 C 与 Rust 的又一次正面交锋。

但如果我们暂时放下语言阵营之间的情绪，这场讨论其实提出了一个很有价值的问题：

当 AI 基础设施开始追求极致性能时，开发者是否正在重新审视那些曾经被认为已经过时的底层编程语言？

为什么 AI 基础设施又开始重视 C？

首先，我们需要理解 xAI 这次重写的对象。

Musk 并没有说要用 C/C++ 重写整个 Grok 模型，也没有说要用 C 替代所有机器学习框架。

他明确提到的是两个部分：

RL（Reinforcement Learning），强化学习技术栈。
Inference，推理技术栈。

这两个领域恰恰是 AI 基础设施中对系统性能非常敏感的部分。

第一，推理系统需要极致的资源利用率。

大模型推理不是简单地执行一次矩阵乘法。

一个生产级推理系统需要处理：

GPU 资源调度。
KV Cache 管理。
内存分配与回收。
请求调度与批处理。
CPU 与 GPU 之间的数据传输。
多 GPU、多节点之间的通信。
并发请求和任务生命周期管理。

这些环节中的任何一个成为瓶颈，都可能影响整个系统的吞吐量和延迟。

尤其是 KV Cache。

随着上下文长度和并发请求数量增加，KV Cache 会占用大量 GPU 显存。如何管理这些缓存、如何减少内存碎片、如何提高显存利用率，直接关系到推理系统的经济性。

这时，底层内存管理能力就显得非常重要。

第二，强化学习系统同样是一个复杂的分布式系统问题。

大模型 RL 并不是简单地调用一个优化器。

在典型的 RL 训练系统中，通常涉及多个角色：

Actor：负责生成动作或回答。
Environment：提供交互环境。
Reward Model：评估生成结果。
Learner：负责策略更新。
Rollout：负责生成训练样本。

这些组件之间需要大量的数据传输、任务调度和同步。

当训练规模扩大时，系统调度、通信和内存管理本身就可能成为性能瓶颈。

第三，C/C++ 能够提供更直接的底层控制。

C 和 C++ 已经在高性能计算、操作系统、编译器、数据库、网络协议栈和 GPU 软件生态中积累了数十年的工程经验。

它们能够让开发者直接控制：

内存布局和分配策略。
数据结构的存储方式。
对象生命周期。
SIMD 指令和底层硬件特性。
与 C ABI、GPU Runtime 以及其他底层组件的集成。

对于追求极致性能的系统工程师来说，这些能力非常有吸引力。

C 与 Rust，究竟在争什么？

要理解这场争论，我们需要回到两门语言最核心的设计差异。

C 的哲学可以概括为：

把控制权交给程序员。

Rust 的哲学则可以概括为：

尽可能在编译阶段证明程序的内存使用是安全的。

两者并不是简单的性能竞争，而是对程序员责任边界的不同设计。

C：自由意味着责任

C 语言没有内置的所有权系统，也没有编译器强制执行的借用检查机制。

程序员可以直接操作指针，申请和释放内存，控制对象的生命周期。

例如：

#include <stdlib.h> #include <stdio.h>  int main(void) {  int *p = malloc(sizeof(int));   if (p == NULL) {  return 1;  }   *p = 42;   printf("%d\n", *p);   free(p);  return 0; }

代码非常直接。

但如果程序员忘记调用 free，就可能产生内存泄漏。

如果在 free 之后继续访问指针，就可能产生 Use-After-Free。

如果重复释放同一块内存，就可能产生 Double Free。

这些问题不会因为 C 语言本身而自动消失。

C 的优势是控制权，代价是程序员必须承担更多责任。

Rust：把一部分责任交给编译器

Rust 引入了 Ownership、Borrowing 和 Lifetime 三个重要概念。

它试图通过编译期检查，在不依赖垃圾回收器的前提下，保证内存安全。

例如：

fn main() {  let s = String::from("hello");   let r = &s;   println!("{}", r); }

Rust 编译器会跟踪变量的所有权和引用关系。

当程序违反所有权规则时，编译器会拒绝编译。

例如：

fn main() {  let s = String::from("hello");   let r = &s;   drop(s);   println!("{}", r); }

这段代码无法通过编译。

因为 s 已经被释放，引用 r 却仍然试图访问它。

Rust 的借用检查器在编译阶段就发现了这个问题。

这意味着很多 C 程序中需要依靠代码审查、测试、动态检测才能发现的内存安全问题，可以在 Rust 编译阶段直接被拦截。

两种语言的设计差异可以简单归纳为：

维度	C	Rust
内存管理	手动管理为主	所有权与借用
内存安全	主要依赖程序员	编译期强制检查
指针操作	高度自由	受安全规则约束
抽象控制	直接、显式	提供丰富的零成本抽象
并发安全	主要依赖程序员	类型系统提供支持
生态成熟度	极其成熟	持续快速发展
学习成本	语言本身相对简单	所有权系统有一定门槛

这里有一个容易被忽略的事实：

Rust 并不意味着牺牲性能来换取安全。

Rust 的设计目标之一就是零成本抽象。它不依赖传统垃圾回收机制，经过优化后，完全可以达到与 C/C++ 相当的性能。

因此，Musk 说 C 能够获得最佳性能，并不能直接推导出 Rust 在性能上存在天然劣势。

真正的差异更多体现在具体实现、工具链、生态、工程团队经验，以及对底层资源控制的需求上。

Rust 的优势，为什么并不意味着 C 会消失？

Rust 这些年发展得非常快。

从 Linux 内核开始接受 Rust 代码，到 Android 将 Rust 用于部分系统组件，再到各种基础设施项目逐渐采用 Rust，它已经不再只是一个有趣的编程语言实验。

Rust 最大的价值，是让系统软件开发者有机会在保持高性能的同时，减少一大类内存安全问题。

尤其是在操作系统、网络服务、数据库、存储引擎和安全敏感组件中，这种能力非常有价值。

但这并不代表 C 就应该退出历史舞台。

事实上，C 的优势并不只是性能。

它还有几个短期内很难被替代的特点：

1. 极其成熟的生态系统。

操作系统、编译器、嵌入式软件、GPU 驱动和大量基础设施，都建立在 C/C++ 生态之上。

替换这些系统，不只是换一种语言，而是涉及整个工具链、ABI、依赖关系和工程体系。

2. 与硬件和现有系统的集成能力。

C 拥有成熟的 ABI 和 FFI 生态。

在很多需要直接对接现有 C 库、硬件驱动和底层 Runtime 的场景中，C 仍然非常方便。

3. 团队经验和工程成本。

对于一支已经积累大量 C/C++ 经验的团队来说，使用熟悉的语言重写关键组件，可能比引入一套新的语言体系更容易控制交付风险。

当然，这只是可能的工程考量，并不代表我们已经知道 xAI 做出这一决策的全部原因。

反过来看，Rust 也有自己的优势。

对于新开发的系统组件，如果项目对内存安全、并发安全和长期可维护性有很高要求，Rust 往往是非常有竞争力的选择。

因此，C 与 Rust 并不是简单的替代关系。

它们更像是两种不同的工程工具。

一个强调最大程度的控制自由，一个试图把更多安全保证前置到编译阶段。

真正优秀的工程师，不应该因为语言阵营而拒绝合适的工具。

AI Agent 会重新定义编程语言吗？

我认为，这场讨论还有一个值得关注的背景：AI Coding Agent 正在改变软件开发的生产方式。

过去，选择一门编程语言，往往需要考虑很多因素：

开发人员是否熟悉？
学习曲线是否足够平缓？
招聘市场是否容易找到人才？
第三方库是否丰富？
开发和维护成本是否可控？

这些因素依然重要。

但 AI Agent 的出现，正在改变其中一部分约束。

过去，使用 Rust 的一个门槛是开发人员需要理解所有权、生命周期和复杂的类型约束。

现在，AI Agent 可以帮助开发者生成 Rust 代码、解释编译器错误、修复生命周期问题，甚至完成跨模块重构。

这并不意味着 Rust 的学习成本消失了，但它确实可能降低日常开发中与语言机制交互的成本。

与此同时，AI 也让 C 这样的语言重新获得了一些关注。

如果 AI Agent 能够辅助开发者处理指针操作、内存管理、边界检查和复杂的底层代码，那么 C 的一些开发门槛也可能被部分降低。

但这里必须强调：

AI 能够生成代码，不等于 AI 能够保证代码安全。

尤其是在 C 这样的语言中，AI 生成的代码同样可能包含缓冲区溢出、Use-After-Free、数据竞争等问题。

最终仍然需要静态分析、动态检测、模糊测试和严格的代码审查。

更有意思的是，AI Agent 可能让未来的编程语言选择更加多样化。

Vercel CEO Guillermo Rauch 在相关讨论中表达过一个值得关注的观点：Rust 有自己的优势，但 AI Agent 可能推动开发者创造更适合特定任务的语言，而不是所有人都依赖一种通用语言。

这个判断值得认真思考。

我们可以设想一个未来的软件工程场景：

开发者描述一个系统的性能、安全性和部署要求，AI Agent 根据具体任务选择合适的语言、运行时和工具链。

例如：

这张图表达的并不是未来一定会出现一个能够自动选择所有语言的万能 Agent，而是一种正在变得合理的工程思路：

语言不再是开发者的身份标签，而是 AI Agent 可以根据任务约束选择的工程工具。

甚至不排除未来出现更多针对特定硬件、特定计算任务和特定 Agent 工作流设计的领域专用语言。

当然，专用语言并不意味着通用语言会消失。编译器、调试器、工具链、生态和维护成本，依然会限制新语言的实际应用范围。

但 AI 确实可能降低语言设计、编译器实现和语言迁移的成本。

这可能是 AI 对编程语言生态带来的一个长期影响。

小结：语言没有信仰，工程只有权衡

回到 Musk 的那句话：

“Rust 是一门好语言，但要在裸金属上获得最佳性能，你应该使用 C。”

这句话有它的工程立场，也有它的争议性。

C 确实拥有极强的底层控制能力，但控制权越大，犯错的空间也越大。

Rust 确实能够通过所有权和借用检查器消除大量内存安全问题，但它也不是所有系统工程场景下的唯一答案。

更重要的是，我们目前并不知道 xAI 为什么最终选择 C/C++，也没有看到这次重写带来了多少实际性能收益。Musk 的发言说明了技术路线，却还不足以证明这条路线在所有维度上都优于原来的方案。

所以，与其争论 C 和 Rust 谁才是未来，不如关注一个更本质的问题：

在 AI 时代，我们应该如何为具体的工程问题选择最合适的技术栈？

我的看法是：

如果你需要极致的硬件控制，C/C++ 仍然值得掌握。
如果你需要高性能与内存安全兼顾，Rust 是非常值得投入的方向。
如果你需要快速构建可靠的后端基础设施，Go 依然是优秀的选择。
如果你需要机器学习和数据科学生态，Python 仍然有不可替代的价值。

未来的软件系统，很可能不是由一种语言统治，而是由多种语言协同构建。

而 AI Agent 会进一步降低跨语言协作的成本。

最后，我想借用 Musk 那句话的后半句：

With great power comes great responsibility.

能力越大，责任越大。

这句话放在 C 语言身上很合适，放在 Rust 身上同样合适。

毕竟，编程语言可以帮助我们减少错误，但最终对软件质量负责的，始终是构建系统的人。

真正成熟的程序员，不应该为自己使用哪门语言而自豪，而应该为自己能够用合适的技术解决复杂问题而自豪。

延伸阅读：

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
构建坚不可摧的 Safety Middleware 与飞书人工审批防线
在底层实现 Token 成本审计、链路追踪与自动化跑分评估
从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

「Go & AI 精进营」已全面升级为「Go, Rust & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 现代系统级开发（Go / Rust） 与 前沿 Agentic AI 工程实践 平台。在这里，你将获得：

体系化 Go 核心进阶内容： 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 语言内功。
硬核 Rust 专项实战赋能： 同步解锁全年 54 讲独家专栏「事不过三：Rust 系统级入门实战课」，通过 4 个里程碑项目（命令行工具、KV引擎、多线程Web服务、异步Redis），带你彻底攻克所有权与并发高山，拿下 Rust 核心壁垒。
前沿 Agentic AI 落地实践： 紧跟时代步伐，系统学习「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实>战」、「Harness工程设计」等，掌握 AI 时代的系统架构新技能。
星主 Tony Bai 亲自答疑： 遇到疑难杂症？星主第一时间为你深度解析，扫清 Go、Rust 与 AI 实践中的学习与工程障碍。
高活跃 Gopher & Rustacean 交流圈： 与众多优秀的技术极客探讨系统设计、分享前沿心得、碰撞思想火花。
独家资源与专栏首发： 博客深度长文、专栏教程更新、精选技术资源，星球会员第一时间触达，加入星球即可免费阅读全套进阶专栏！

衷心希望「Go, Rust & AI 精进营」能成为你拓宽技术边界、持续精进与交流的温暖港湾。让我们在此相聚，享受代码与工程之美以及技术精进>的快乐！欢迎你的加入！