Rust并非系统编程的未来——它只是炒作周期
多年来，Rust 一直被誉为系统编程的救世主。它承诺内存安全、接近 C++ 的性能以及现代工具链。它拥有活跃的社区、赞誉如潮的博客文章，甚至被微软和 Dropbox 等公司采用。但让我们暂停片刻思考：Rust 真的是系统编程的未来，还是只是炒作周期中的又一站？
我倾向后者。Rust在诸多方面堪称卓越，但其陡峭的学习曲线、漫长的编译时间以及复杂的抽象机制，注定会阻碍其大规模普及——正如数十年前C和C++的固化发展路径。让我们逐层剖析这一论点。
编译时困境
Rust的编译时长素来令人诟病。尽管存在优化技巧和夜间构建版本，但开发者实际仍需耗费大量时间等待。
示例对比(小型基准测试)：
# C++ (g++)
$ time g++ main.cpp -o main
real 0m0.4s
# Rust (cargo build --release)
$ time cargo build --release
real 0m9.7s
在如此简单的示例中，Rust竟慢了20倍以上。面对大型代码库时，等待数分钟完成构建实属常态。这导致开发效率急剧下降，迭代速度严重受阻。宣称具备现代生产力的语言，实在无法承受如此代价。
学习曲线
Rust的所有权模型既具革命性又充满挑战。借用、生命周期和引用在理论上精妙绝伦，实践中却令新手望而生畏。
C++中的简单函数：
string greet(const string& name) {
return “Hello, ” + name;
}
Rust对应实现：
fn greet(name: &str) -> String {
format!(“Hello, {}”, name)
}
看似无碍，直到你尝试返回借用数据、处理生命周期，或编写稍复杂的代码。编译器随即发出警告：
error[E0515]: 无法返回引用局部变量的值
这是Rust的必经之路——与借用检查器周旋直至重写逻辑三次。对老手而言是成长，对新手则是煎熬。
复杂性与普及度
问题不在于Rust本身糟糕，而在于系统编程依赖稳定性和易用性。C语言之所以称霸，正是因为它 简单 且易于学习。相比之下，Rust要求程序员必须掌握所有权语义、生命周期、特质和宏才能高效编程。
以下是可视化对比：
C语言代码结构：
+ main.c
- main()
- helper()
Rust项目结构：
+ Cargo.toml
+ src/
- main.rs
- lib.rs
- modules/
- mod1.rs
- mod2.rs
Rust 早期就强制要求遵循约定、使用模块和宏。这对大型项目很有帮助，但对于小型或嵌入式系统而言，则显得有些过度设计。
迁移决策树
若团队正在考虑是否采用 Rust，以下粗略但实用的指南可供参考：
内存安全是否是首要考量？
├── 是 → 能否承受较长的编译时间和陡峭的学习曲线？
│ ├── 是 → Rust可行
│ └── 否 → 继续使用带内存检查器的C++
└── 否 →
├── 需要可移植性与现有生态？→ 使用C
└── 需要性能+现代抽象？→ 使用C++
当内存安全至关重要时(如操作系统内核、密码学领域)，Rust 表现卓越；但在多数实际场景中，其权衡代价并不值得付出。
技术炒作周期
若将 Rust 置于 Gartner 技术炒作周期图中，其轨迹如下：
过高期望峰值
/
/
Rust ---------/
/
/ ← 当前所处位置
/ (幻灭低谷)
众多开发者正遭遇编译时长、工具怪癖及实际应用困境的瓶颈。Rust在特定领域表现卓越，但难以大规模取代C或C++。
客观视角
Rust是卓越的工程杰作。它迫使我们重新审视数十年来忽视的内存安全问题，推动着整个行业进步。但认为它能直接取代C或C++？这纯属幻想。
它最可能在操作系统内核、区块链及安全关键型代码库中开辟出可敬的细分领域。但在更广阔的系统编程世界里，简洁性、工具链以及C/C++数十年的统治地位所形成的惯性过于强大。
Rust并非系统编程的未来。它只是当前炒作周期中的产物——如同所有周期，它终将落脚于细分领域，而非登顶王座。
最后思考
请以它本来的面目来赞美 Rust：作为一款强大、安全且现代化的工具，它完美适用于特定高风险领域。但切勿将炒作与命运混为一谈。系统编程的未来不会属于单一语言——它将属于多种语言，Rust 亦在其中，但绝非唯一的继承者。
本文文字及图片出自 Rust Isn't the Future of Systems Programming — It's Just the Hype Cycle
关于哪种语言更适合新手的比较颇有意思。我认为这些语言对初学者都不算简单。我不觉得C(++)在此能展现优势。对系统编程初学者而言，Go语言显然更易上手。若论编程语言的普遍适用性，市面上还有许多比C(++)和Rust更易学习的选择。
> 我不明白C(++)在此有何优势[..] Go会容易得多
C与C++的复杂度存在天壤之别。C语言本质上相当易懂(除某些语法怪癖外)，类似当年Turbo Pascal的特性。反观Go语言，其诸多特性对初学者颇具挑战(例如规则繁复的接口，以及值接收器与指针接收器带来的复杂影响)。自从引入泛型后，Go的复杂度更是一跃而起，在复杂性层面已与C渐行渐远，更趋近于C++。
我虽熟悉几种基于垃圾回收的语言，但就其他语言而言：
C语言易学难用，C++难学难用，Rust难学易用。Rust是我真正能掌握并运用的语言之一。
抛开大型语言模型的写作不谈，这个论点根本站不住脚。它试图论证“Rust存在这些缺陷，因此无法取代C/C++”，却未提出(或未意识到必须提出)中间论断：“C/C++不存在这些缺陷/Rust未能提供足够吸引人的特性来弥补这些缺陷”。
更荒谬的是它采取双重标准：既将C与C++混为一谈，又刻意强调C的简洁性来反衬Rust的复杂性…却对C++的复杂性视而不见，仿佛二者可互换。所谓Rust开发者遭遇工具链怪癖就该弃用Rust转投C++的论调，简直荒谬绝伦。
我认为这篇文章有其道理，尽管不同意其论点。二十年前的C++确实简单，但如今呢？我认为它与Rust不相上下。两者都拥有可供坚持使用的简洁核心。
说项目目录结构复杂简直荒谬，公平的对比对象应该是C++那令人脑洞大开的通用包/依赖管理机制。
他们确实说对了：我期待能创造出兼具速度、安全性和 简单易用 的语言。当前我们面临取舍三角：Rust比C++安全，速度相当，但使用难度更高。总得有所取舍。
文章确实指出C语言易于上手，这无疑推动了软件的爆炸式增长。
二十年前C++就绝非简单！我们早有模板元编程，还经常争论该同意使用语言的哪些子集才能确保安全。即便那时也没人能完全理解它。
没错。杂志上甚至常设C++谜题专栏，要求读者破解代码功能。正是通过这种方式，模板元编程最终崭露头角——当几位天才发现可用它实现条件判断和循环时，连语言发明者都未曾预见的可能性就此诞生。所以C++98绝非简单，但无疑比今天的C++简单得多。
无论文章是否由AI生成，我更倾向于支持自动资源管理，并改进低级编码的类型系统——无论是仿射类型、线性类型、效果类型、证明类型还是依赖类型，选择空间都相当广阔。
值得注意的是，只要Rust仍依赖C++作为核心编译器后端，它就无法完全取代C++。
最后，即便这只是泡沫，AI驱动的编程正使特定语言逐渐失效——最终仅AI语言运行时需要在底层精细控制所有机制。
或许未来将是AI语言编译器直接生成机器码，其生产力将媲美施乐帕克工作站、Lisp机器或Bret Victor的构想。
> 唯有AI语言运行时需要精细控制所有运作机制
若AI能比C++更理解Rust文档，Rust就能胜出 😀
既然终极目标是直接获取机器码或实现自主行动的智能体？
生成现有编程语言只是过渡阶段，正如汇编语言程序员曾对早期优化编译器持怀疑态度，他们期望通过多步流程：先由编译器生成可审查的汇编代码，再运行汇编器处理。
我们需要秉持艾伦·凯的视角——不局限于当下AI工具的能力，而应展望数十年后的可能形态。
当内存安全至关重要时(如操作系统内核、密码学领域)，Rust便大放异彩；但在多数实际场景中，其权衡取舍并不值得付出代价。
你开玩笑吧…
内存安全在无数场景中都是巨大优势。我认为这是常态而非例外。若再结合其卓越的性能表现，Rust便具备极强的吸引力。我对 Rust 的了解尚不足以评判其取舍，但上述观点本身就显得相当愚蠢。
至于所谓的“炒作周期”，Rust 已经历经多次软件炒作浪潮的洗礼，如今早已站稳脚跟。文章中所谓“终于进入炒作中期”的说法既缺乏依据，也难以成立。
若炒作不是关键因素，TypeScript在任何维度都不可能比Java更受欢迎
为何此帖被标记？
因为Reddit存在针对特定话题的压制异见行动。
Rust正是其中之一。想被举报和踩分？写篇批评Rust的文章就行。
光是提及此事就足以招致踩分。
> 若想被标记和点踩，只需写篇批评Rust的文章。
胡说八道。在HN上找到广受好评的Rust批判内容并不难(例如快速搜索就有[0, 1, 2]等大量案例，尤其围绕async和/或deps模块)。关键在于提出有实质内容/深思熟虑/建设性的批评。事实上这适用于所有领域——无论讨论什么话题，有深度/有见地/建设性的文章/评论都更容易获得好评。
本文确实触及了Rust的一些弱点/痛点，但处理方式简直糟糕透顶。开篇就出现这样的代码：
没错，Rust的编译时间确实可能较长，但若想证明这一点，这简直是最糟糕的方式——不仅没有做到公平比较(将调试构建与发布构建相提并论)，而且 我们甚至不知道具体编译了什么内容 ！
后续内容更是每况愈下。比如这段：
> 突然间，编译器开始发出警告：
没错，这确实是错误。 C++中同样存在此问题 。事实上，C++26也把(某些形式的？)这种情况定义为硬性错误，可见C++正朝着与Rust一致的方向发展。
代码组织示例再次未能做到公平比较。更何况它本身就是错误的。
迁移决策树同样存在矛盾。若“内存安全是首要考量”，那么带内存检查器的C++显然不应是可行选项。
诸如此类的问题比比皆是。若想撰写受认可的Rust批判文章，这绝非正确方式。
[0]: https://news.ycombinator.com/item?id=40172033
[1]: https://news.ycombinator.com/item?id=36239534
[2]: https://news.ycombinator.com/item?id=41791773
这个网站上充斥着更多肤浅的内容，甚至能获得数百个赞。你并未解释为何这篇被标记。
> 这个网站上充斥着更多肤浅的内容，甚至能获得数百个赞。
没错，但某条内容获得某种反馈而另一条获得不同反馈的事实并不能说明什么，毕竟HN并非铁板一块。不同用户阅读不同内容，对标记内容的门槛也各不相同，诸如此类。
> 你并未解释为何标记此内容。
我的评论不正是试图解释为何该帖被标记吗？
况且我也无法给出确切的标记理由：首先，我不知道HN的软件如何判定标记行为；其次，我无法揣测每个标记者的心思，更遑论判断他们的理由是否“合理”(假设我有资格评判的话)；最后—— 我根本不知道文章是否被版主人工标记。当然可以猜测，但我的猜测价值未必比你的高。
若发现文章被标记却认为不该如此，最佳解决方式是为其担保，若无效则联系版主。
好，现在讨论这篇文章。你能举个例子说明你喜欢文章的哪些部分吗？
你这账号90%都在吐槽Rust。考虑找份正经工作吗？
这纯粹是毫无实质内容的煽动性言论。就像编造基准测试却不说明对比对象。展示实际可运行的代码，却附上与该代码无关或非其引发的错误信息。诸如此类。
大概是因为这是大型语言模型生成的内容，正如其他评论所指出的。
谁能确定呢？这听起来像是种无法证伪的指控，可以用来否定任何观点。
正如其他评论所言，这篇及他们所有帖子都是AI生成的。
https://cachecowboy.medium.com/
陡峭的学习曲线意味着你在短时间内(纵轴)学到大量知识(纵轴)。因此曲线会快速上升(陡峭)。
作者若要发表如此耸人听闻的论断，至少该用对术语…
不，“陡峭的学习曲线”这个说法暗示学习过程艰难，因此进展可能缓慢。
这其实是个误称。你对图表的解读没错，但该短语实际表达的是相反含义。
这是AI生成的内容，看起来只是标准化的C++应对方案。不明白为何要花时间反驳它或重新考虑我的系统架构。
反驳这个https://www.youtube.com/watch?v=hkNLVQHZHk8
没什么好反驳的。这不过是常见的恐慌性错误，已被识别并修复。
录制视频者言语狂躁，除了偏见情绪外毫无实质论点。这恰恰印证了我上述观点。
[已删除]
> 说到狂躁，这已是几分钟内你第三次彻底重写回复了
说起躁狂，是你自己数着几分钟内改了多少次回复，谁才像躁狂症患者？
重申——根本无从反驳。视频里唯一的指控是存在针对C++用户的巨大阴谋，这只会让Chris Lattner捧腹大笑。
若真由你录制该视频，希望你能释怀。处理悲伤的方式远比在三个HN账号上抱怨更值得推崇。
> 若真由你录制该视频，希望你能释怀。处理悲伤的方式远比在三个HN账号上抱怨更值得推崇。
根据头像和频道其他视频判断，合理推测频道主应是C++ fast_io库[0]的作者。过去几年他多次公开表达对Rust等技术的厌恶，短期内态度恐难改变。
关于ls_a是否与频道所有者有关联不予置评；只是想对视频上传者提供更多背景信息。
[0]: https://github.com/cppfastio/fast_io