2026-06-14 08:34:27
本文永久链接 – https://tonybai.com/2026/06/14/stop-saving-tokens-silicon-valley-consensus-waste-compute-shortcut
大家好，我是Tony Bai。
你是不是也曾在写 Prompt（提示词）时斤斤计较，为了省下那几元钱的 Token 而字斟句酌？你是不是也曾疯狂收藏各种“保姆级提示词教程”，试图摸索出调教大模型的“终极秘籍”？
快停下这种低效的行为吧。在真正的硅谷科技巨头和顶级创始人眼里，你这种抠抠搜搜的省钱方式，正在浪费你这辈子最昂贵的资源——时间。
在最新一期的硅谷教父 Naval and Nivi Podcast 闭门在线圆桌会议上，Naval 邀请了三位极其硬核的“前沿造物主”：
在这场几乎没有水分的对话中，大佬们抛出了一个在当今开发圈极具毁灭性、却又无比清醒的论点：
“别去学那些花里胡哨的提示词技巧了。扔掉预算表，直接用最粗暴的方式把 Claude、Gemini、Codex 砸向同一个问题。垃圾代码万岁，浪费 Token 才是大模型时代的唯一捷径。”
现在的中英文互联网上，充斥着各种教你如何写“完美提示词”的收费课程。但在真正的硅谷巨头眼里，这些技巧无异于“刻舟求剑”。
“我完全无视了那些所谓的‘提示词技巧和框架’，”脑机接口巨头 Science 的创始人 Max Hodak 坦言。
“什么‘使用 Ralph Wigum 模式’、‘引入 OpenClaw’、‘配置这个脚手架’……我全都不管。我默认一个事实：大模型自身进化的速度，远远快于人类摸索提示词技巧的速度。它研究我怎么说话，绝对比我研究它怎么理解要快得多。”
Max 揭示了一个极其粗暴但无比爽快的底层策略：暴力破解（Brute Force）。
当他遇到一个复杂的系统工程问题时，他不会花三个小时去润色一条完美的 Prompt。他会选择直接写几句甚至带着语法错误的、大白话般的意图，然后同时塞给 Codex、Claude 和 Gemini。他不在乎 API 的账单，他只在乎谁先给出对的结果。
“词元（Token）再贵，也比人类的时间便宜。浪费词元，拯救时间，这就是全部的秘密。”
在传统的研发团队中，说某个程序员是 “10x 程序员（十倍效能）”往往会引发极大的争议，因为它挑战了传统的“人人平等”观念。
但 Naval 指出，在数字和虚拟的世界里，人与人的差距从来就不是 10 倍，而是 100 倍、1000 倍甚至无限大。
“发明 JavaScript 的 Brendan Eich，写出 3D 引擎的 John Carmack，创立比特币的 Satoshi（中本聪）——这些都是 1000x 级别的神仙。”
而在 AI 编排引擎的加持下，这种“1000x 程序员”正在以一种全新的形态复活。
Vercel 创始人 Gumo 提出了一个颠覆性的论点：未来程序员的工作，不再是“交付具体的代码代码”，而是“建造生产代码的工厂”。
[传统工程师] ───> 编写 ───> [具体的业务代码 B] (低效，线性)
[1000x 工程师] ───> 建造 ───> [AI 软件工厂] ───> 自动化裂变 ───> [代码 B 到 Z] (指数级)
以前，衡量一个工程师的价值是：他写代码的速度有多快，交出的 Bug 有多低。
现在，衡量一个工程师的价值是：他能否构建起一个自动化、自省的 AI 开发流水线（The Software Factory），让这个工厂去自动产生从 B 到 Z 的无数代码。
在软件工厂（Software Factory）范式下，未来的开发不是写代码，而是设计生产代码的机器。平庸的、只会机械搬砖的程序员会迅速贬值；而那些具备高阶系统设计能力、超强架构直觉的 1000x 工程师，其生产力将被放大到令人颤抖的维度。
近两年，硅谷流行起了一个新词——Vibe Coding（氛围编程）。很多人觉得这只是一个娱乐化的自媒体词汇，但 Naval 却一针见血地指出了它的物理本质：
“其实，一个优秀的研发总监或 CTO，在过去几十年的职业生涯里，一直都在进行‘Vibe Coding’。”
想想看，一个资深架构师或 CTO 每天在干嘛？他们并不亲自去写底层的每一行API/数据库调用。他们通过 飞书、Jira、设计文档，向团队传输他们的意志、设计哲学、业务直觉和品味（Taste & Judgment）。
他们给出边界和期望，然后让团队里的初级程序员们去补充细节、去踩坑、去实现。
“现在，人类只是把传递意志的对象，从‘初级程序员’换成了‘AI 智能体’。”
你把大方向和架构考量（比如：不要用 MongoDB，这里我们需要高强度的事务一致性，给我上 PostgreSQL）输入给 Agent，然后让它去疯狂搬砖。这正是最纯粹、最硬核的“氛围编程”。
AI 让所有具备“系统大局观”的人类，在瞬间拥有了数十个不知疲倦、随时待命的虚拟技术团队。
如果代码生成已经变得如此廉价，那未来软件公司的“护城河（Moat）”到底在哪里？如果 AI 能够一键生成任何软件，那我们还需要构建底层的软件工程吗？
Gumo 和 Naval 探讨了 Mitchell Hashimoto 提出的 “积木经济（Building Block Economy）” 概念。
“我们绝对不能指望 AI 每次面临一个新任务时，都从第一性原理出发去重新发明一遍轮子。”
如果你的 AI Agent 需要发送一封邮件，它不应该去自己从底层协议重构一个邮件收发系统；它应该去调用已经存在的、在人类社会中经过千万次锤炼的安全积木——比如成熟的 Queue 系统、PostgreSQL 数据库。
大模型最核心的资产不是去搞无意义的“重复创造”，而是重用人类文明已经沉淀好的、高鲁棒性的“技术积木”。
因此，在 AI 时代，真正的壁垒将分化为两个极端：
在这场硬核的围炉对话中，大佬们用最前沿的视角，为我们描绘了一个充满希望的未来。
Max 提到，他自己已经有 20 年不写代码了。但由于 AI 工具的爆发，他重新找回了年少时在电脑前废寝忘食、疯狂创造的快乐。在过去几个月里，他完全通过 Agent，为自己构建了数个每天都在高频使用的完整软件系统：
“在过去，你写代码时总会卡在某个愚蠢的依赖配置或编译报错里，一卡就是好几天，极其挫伤积极性。而现在，有了 Agent，你永远不会再卡住了（You just don’t get stuck anymore）。”
这是一场属于人类创造力的伟大解放。
当我们不再需要把生命浪费在无休止的“底层配置对齐”和“样板代码套娃”中，当我们学会大把大把地“浪费”廉价的 Token 去换取珍贵的时间，我们才真正夺回了作为“建造者（Builders）”的尊严。
我们不再是手持泥铲、在工地上砌砖的泥瓦匠；我们是坐在直升机上、挥洒着无尽算力、俯瞰整个数字新城拔地而起的巨擘。
资料链接：https://www.youtube.com/watch?v=aiyf-5jmYf0
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-06-13 07:13:00
本文永久链接 – https://tonybai.com/2026/06/13/linux-maintainer-greg-kh-switched-to-rust-after-35-years-of-c
大家好，我是Tony Bai。
在开源软件的宏大版图中，Linux 内核无疑是那座最古老、最庞大、也最不容有失的钢铁巨塔。它由数千万行 C 语言代码铸就，运行在世界上每一个数据中心、每一台智能手机，乃至公司的投影仪和麦克风里。
在这个由 C 语言统治了三十多年的“神圣领域”，任何关于引入新语言的提议，都曾被视为不可理喻的异端。
然而，巨变正在悄然发生。
在最新一期的 Rust in Production 播客中，两位行业殿堂级人物坐在一起，进行了一场载入 Linux 史册的对话，揭示了 Linux 内核史上最伟大的语言融合：
在这场深度对话中，Greg 坦言自己曾是一个坚定的“Rust 怀疑论者”，但现在，他不仅公开宣布 “Linux 引入 Rust 的实验已经结束，它已经是正式项目”，更说出了一句让无数技术人动容的话：
“Rust 让我觉得，写程序重新变得有趣了。”
为什么一个掌控着世界底层算力命脉的 C 语言守护神，会被 Rust 彻底征服？在 Linux 这个极致复杂的系统级工程里，Rust 究竟带来了怎样的化学反应？
在 Linux 内核这样不容许任何安全妥协的底层项目中，引入一门新语言，最大的挑战是什么？
Alice 和 Greg 给出了同一个反直觉的答案：最大的挑战不是技术，而是社会学（Social Challenge）。
“内核的运转，本质上是基于对‘人’的信任。”Greg 解释道。
在 Linux 社区，每天都有几千名开发者提交补丁。资深维护者们并不指望任何人写出完美无缺的代码，因为“我们都会犯错”。
“我们信任你，不是信任你的代码不会出错；而是信任当代码出错、系统崩溃时，你会守在电脑前把它修好。”
在过去的二十年里，有很多系统编程语言（比如 C++）曾试图叩开 Linux 内核的大门，但它们的倡导者写完代码就走了，没有人愿意留下来承担那份沉重、枯燥的长期维护责任。
而 Rust 社区的先驱们用了整整 8 年时间，在内核树外（Out of tree）默默编写驱动、完善基础设施，用实际行动向 Greg 这样的内核守门人证明：“我们不仅能写出安全的代码，而且我们做好了准备，会留在这里和你们一起修 Bug。”
正是这种长期主义的务实精神，建立起了难能可贵的信任（Trust）。
当 Rust 真正开始深入内核的毛细血管时，发生了一个极其奇妙、甚至带有一丝讽刺意味的现象：即使你完全不碰 Rust 代码，原本的 C 语言代码也因为 Rust 的到来而变得更好了。
Alice 分享了她们在编写绑定（Bindings）时的技术细节。在 C 语言中，一个指针的定义往往是极其模糊的：
// C 语言中的经典指针返回
struct device *get_device_info(void);
这个指针返回后，调用者需要面对一系列拷问：
在 C 语言的签名里，这些信息全部是缺失的，只能靠开发者查阅文档、或者在脑海里默默推理。
但当 Alice 试图为这段 C 代码编写 Rust 包装器（Wrapper）时，由于 Rust 编译器的强制要求，她们必须在 Rust 签名中明确定义：它是 Arc，是 Box，还是一个简单的引用（Reference）？
为了让 Rust 编译器满意，Rust 团队不得不去倒逼 C 语言维护者厘清这些指针的语义。
“在很多地方，写 Rust 绑定的开发者需要写几百行复杂的代码，就为了兼容某个极其难用的 C 语言接口。”Greg 笑着回忆道，“我看到后说：‘其实我们可以直接修改 C 语言代码，让它变得更简单。’ 那些写 Rust 的人惊呼：‘噢，原来还可以这样！’”
“即便 Rust 在今天突然消失，Linux 的 C 语言代码库也因为 Rust 曾经来过，而变得比以前安全、清晰、健壮得多。” 这是 Greg 给出的极高评价。这种跨语言的协同审视，正在洗礼整个 Linux 内核的工程素养。
在很多开发者的刻板印象中，写底层的内核核心（如调度器、内存分配器）是最难的，而写外围的“驱动（Drivers）”是最简单的。
Greg 站出来彻底纠正了这个偏见：“在内核中，写驱动才是最难的。因为驱动虽然看起来是树叶，但它在疯狂地消费整棵树干的养分。”
Alice 在为 Android 编写 Rust 驱动时，深刻体会到了这一点。一个驱动为了运转，必须去调用内存分配（Alloc）、调用 I/O 模块、调用网络包分析、调用文件系统。这意味着，你要写一个 Rust 驱动，你就必须先把这所有涉及到的 C 语言核心模块，全部写出对应的 Rust 绑定。
很多人问，为什么不能直接用 Rust 标准库里的 alloc？
因为 Linux 内核的内存分配（malloc）绝非易事。它不是简单的“要一块内存”，而是充满了极其细微的上下文提示（Gfp flags）：
为了满足这些变态的底层硬件级要求，Rust 用户态标准库那一套内存分配器根本无法工作。Rust for Linux 团队不得不完全剥离了 std，甚至重写了适用于内核特性的定制版 alloc 库。
为了解决这些极其精细的内核场景，内核团队甚至编写了专属的编译器插件——Klint（Kernel Lint）。
在内核开发中，有一个铁律：在持有某些特定锁或处于中断上下文时，绝对不允许发生系统休眠（Sleep）。如果 C 程序员犯了这个错，系统往往会直接卡死、甚至死机，极难调试。
而 Klint 作为一个 Rust 编译器插件，能够利用编译期的类型系统，在编译时直接扫描整个代码路径，一旦发现你在不允许睡眠的上下文中调用了任何可能触发睡眠（Sleep）的函数，直接报编译错误！
这种在编译期就把低级内存与调度错误彻底掐灭的能力，是传统的 C 语言静态分析工具（如 Coccinelle）在不破坏代码可读性的前提下，永远无法企及的高度。
当主持人问及，C 程序员能从 Rust 身上学到什么时，Greg 的回答没有滔滔不绝的说教，反而充满了真诚与坦然。
“过去，当我写 C 语言时，如果要在两个模块间传递一个指针，我必须在脑海里进行高强度的思想斗争：这个指针是谁在持有？生命周期对不对？我有没有在别处释放它？”
“当我接触到 Rust 之后，我发现，Rust 帮我把这些繁琐、痛苦、容易出错的 meta-stuff（元认知开销）全部承担了。”
“编译器编译通过了，逻辑看起来也是对的。好了，我现在可以百分之百地把精力放在我的业务逻辑本身，而不需要去担心那些低级的内存越界和空指针问题。”
“写了 35 年的 C，Rust 让我重新觉得，编程是一件纯粹且快乐的事情。”
这或许是一个程序员，对一门新编程语言所能表达的最高敬意。
在对话的最后，现场响起了经久不息的掌声。
Linux 的伟大，不在于它用了 30 多年的 C 语言，而在于它拥有一个极其开放、务实且充满活力的工程文化。当有更好的工具出现时，这些掌控着世界算力命脉的守护者们，没有抱残守缺，而是选择张开双臂，去拥抱改变。
从 Python 狂飙的 AI Agent 调度层，到 Go 统治的云原生 Agent编排底座，再到 Rust 正在接管的 Linux 内核最深处——无论上层的应用和模型如何演进，底层的系统工程（Systems Engineering）依然需要人类最顶尖的逻辑、同理心与工匠精神去雕琢。
我们有幸见证这场跨越语言与时代的融合，更有幸与这些伟大的建设者们同行。
资料链接：
今日开放讨论：
Greg 提到“Rust 绑定的过程，反过来倒逼并简化了 C 语言的原生接口”。在你的项目或日常重构中，是否也曾因为引入了更严苛的约束（如类型系统或静态检查），反而帮助你理清了原本混乱的业务逻辑？
欢迎在评论区分享你的跨语言协作与架构重构故事，我们一起聊聊代码的纯粹之美！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-06-12 08:28:07
本文永久链接 – https://tonybai.com/2026/06/12/zig-father-refuses-funding-bans-ai-why-no-1-0-in-a-decade
大家好，我是Tony Bai。
在技术圈，有一门名为 Zig 的系统级编程语言，它没有铺天盖地的营销，没有背后财大气粗的金主干爹，甚至它的代码仓库在 2025 年末从 GitHub 直接“硬核跑路”到了 Codeberg。
然而，在 JetBrains 发布的“最受敬仰编程语言”榜单中，它赫然位列 Top 5；Uber 用它的编译器解决 Go 的交叉编译难题；大热的 JavaScript 运行时 Bun 用它作为底层的胶水语言（注：近期Bun已经从Zig迁移为Rust实现）；金融级数据库 TigerBeetle 更是基于它实现了比传统方案快上千倍的性能。
为什么在拥有了 C++、Rust 和 Go 之后，世界依然需要 Zig？
最近，JetBrains 团队对 Zig 之父 Andrew Kelley 进行了一次深度专访。在长达一个多小时的访谈中，Andrew 展现出了极度“反主流”的极客态度：坚决抵制 AI 生成的代码（No-AI Policy）、宁可拿 67 万美元的非营利基金也不要上亿美元的投资、10 年不发布 1.0 版本。
今天，我们就来深度扒一扒，这位被称为“最硬核系统语言创造者”背后的狂人哲学。
故事要从一个开发“数字音频工作站（DAW）”的失败尝试说起。
在 2015 年之前，Andrew 试图用各种现有的语言去开发一个专业的 DAW 软件。
即使退回到只用极简 C++（搭配 C 链接器），他依然在不断地“搬起石头砸自己的脚”。
那一刻，年轻的 Andrew 迸发出了极大的傲慢与决心：“我可以做得更好！我可以比 C++ 做得更好，比 Rust 做得更好，比 Go 做得更好！”
于是，Zig 诞生了。
很多人会问：C 语言统治了底层 50 年，Rust 现在红得发紫，Zig 凭什么挤上牌桌？
Andrew 给出了一个极其精准的定位：“在 Zig 中，你不需要像在 Rust 中那样为了迎合编译器的‘类型理论’而去扭曲你的代码结构；在 Zig 中，你思考的是‘我希望 CPU 做什么’，然后你写出让它这么做的代码。”
“想要替代 C，你不能放弃任何 C 拥有的能力。”Andrew 说道。
Go 放弃了底层的绝对控制权换取了并发的便利，所以 Go 永远无法替代 C 写操作系统内核。
但 Zig 做到了。在 Zig 中，一切都可以像 C 一样高效，但消除了 C 语言海量的“坑（Footguns）”。甚至在细节上，Zig 比 C 更像 C：C 语言只有溢出（Wraparound）的无符号整数，而 Zig 允许你精细控制整数的溢出行为和符号约束。
Rust 的核心是其宏大的类型系统和基于生命周期/借用的内存管理模型（类似 RAII）。
而 Zig 走的是“显式分配器（Explicit Allocators）”的路线。
在 Zig 中，没有隐式的内存分配，开发者经常针对特定应用使用 Arena Allocator（一次性分配，一次性销毁），以获得极低的延迟和极高的吞吐量。TigerBeetle 数据库就是利用这一点，在启动时预先分配好所有内存，此后运行时零动态分配（Zero Dynamic Allocation），从而实现了恐怖的高频交易性能。
如果你问一个开发者，在 C/C++ 项目里最痛苦的是什么？99% 的人会回答：配置构建环境（CMake、Makefile、装依赖）。
Zig 的杀手锏在于它的工具链：它没有任何外部依赖。 无论你在什么操作系统上，想要编译一个项目，永远只需要一句 zig build。不仅如此，Zig 甚至可以作为一个超级强大的 C/C++ 交叉编译器。Uber 就是用 zig cc 来解决 Go 语言中混合 C 代码在 ARM 架构上的交叉编译难题的。
在这个“万物皆可 AI 编程（Vibe Coding）”的狂热时代，Andrew 和 Zig 社区制定了一项极其强硬的规则：严禁任何由大模型（LLM/AI）生成的 Issue 和 Pull Request。
为什么这么刚？Andrew 的回答充满了工程师的辛辣与无奈：
“因为那些贡献无一例外，全是垃圾（Invariably garbage）。”
Zig 的核心团队只有 5 个人，却要面对海量的社区贡献。开源项目接受 PR 的核心目的不仅仅是为了拿代码，更是为了“导师制（Mentorship）”——通过 Review 代码，培养出下一代的核心维护者。
但在 Andrew 看来，那些用 AI 批量生成代码然后扔过来的贡献者，不仅没有任何价值，还在疯狂消耗核心团队极其宝贵的 Review 时间。
“这就像是‘贡献者扑克（Contributor Poker）’。用 AI 的人永远只是路过，他们学不到任何东西，也永远不可能成为核心团队的一员。更可笑的是，他们往往只是把报错信息贴回 ChatGPT，然后假装自己修复了问题。这纯粹是在浪费所有人的时间。”
面对满天飞的“AI 编程神器”，Andrew 有着自己极其古典的软件信仰：
“我想要软件拥有‘绝不妥协的完美（Uncompromising perfection）’。我不想看到一个软件仅仅是因为‘出乎意料地没有 Bug’而沾沾自喜，那是一个糟糕透顶的质量标准。”
在科技圈，一个流行的开源项目很快就会被大厂收编，或者拿到顶级 VC 的上亿美元融资，然后迅速扩张。
但 Zig Software Foundation (ZSF) 走了一条截然不同的路。它是一个注册在美国的 501(c)(3) 非营利组织。2024 年，整个基金会的总收入只有区区 67 万美元（约合人民币 480 万）。
在这 67 万美元中，Andrew 为自己定下了 15.4 万美元的年薪（相当于纽约一个普通的资深程序员薪水），而剩下的资金的9成以上，全部用来支付另外几位兼职和全职的外包核心开发者。
当主持人犀利地问道：“如果一家大公司给你 1 亿美元的无条件赞助，你会要吗？”
Andrew 的回答展现出了极度的清醒：
“我会拿，但我会把它存进银行，确保我们未来 100 年都不需要再到处筹款。但我绝不会用这笔钱去扩张。我不想管理 100 个人的团队。”
他的逻辑极其自洽：保持一个极度精简、高效的微型组织，能够最大程度地抵御资本的腐蚀（Oxidation）。
“我们不是初创公司，我们没有投资人在背后催着我们变现。如果我们拿了大厂的钱，他们就会有控制权；现在，我们靠着多元化的小额赞助和少数企业的资助活着。如果哪天某个赞助商说‘你必须按我说的做’，我们可以硬气地回答：‘对不起，如果你撤资，我们依然能活下去。’”
这就是他宁可手写报税单，也要死守非营利基金的底层原因——他要为 Zig 争取“对世界说‘不’”的自由。
为了这份独立和自由，Andrew 付出了很多代价。
2022 年，他退出了 Reddit 和 Twitter。2025 年底，当发现 GitHub 的持续集成（CI）服务器对 Zig 极度不稳定时，他更是做出了一个惊世骇俗的决定：将 Zig 的主仓库从 GitHub 彻底搬迁到了一家德国非营利组织运营的平台 Codeberg。
这意味着他主动放弃了 GitHub 带来的巨大流量和打赏（Sponsors）收入。但他毫不在意：“我们是来写软件的。如果 CI 跑不通，我们就换一个能跑通的。Codeberg 是非营利组织，比那些为了下一个财报季奔波的创业公司靠谱多了。”
那么，被粉丝催了 10 年的 Zig 1.0 究竟什么时候出？
Andrew 坦言，1.0 本质上是一个“向后兼容的承诺”。像 Go 这种语言，1.0 之后很久没动过语法；而 Rust 虽早早发布 1.0，却靠着 Editions（版次）机制继续大改特改。
“我们不需要为了迎合风投的胃口，或者为了所谓的‘商业落地指标’去急匆匆地发布 1.0。当 Zig 1.0 发布的那一天，它必须是一份‘毫不妥协的热爱之作’。我们不需要为任何仓促的糟糕决定买单。”
不过，Andrew 也在采访中透露了一个彩蛋：他将全力冲刺即将到来的 0.16 版本 (注：截至发稿时，Zig官网已经发布了0.16.0版本)。在这个版本中，完全摆脱对 LLVM 依赖的自研 x86 后端将迎来爆发——百万级代码库的增量编译将低至恐怖的 50 毫秒！
在访谈的最后，当被问及“未来 20 年人类还会写代码吗”，Andrew 的眼中闪烁着光芒：
“人们永远不会停止写代码，因为写代码真的太好玩了。”
在他看来，当今世界最好的软件，往往是开发者们在业余时间出于热爱而写的。而那些为了商业目的强加给用户的软件，总是充满了广告、诱导和恶意的参与度指标。
Zig 不仅仅是一门编程语言，它是 Andrew Kelley 献给世界的一份“无条件的礼物”。它在向所有热爱底层、渴望掌控计算机的极客们宣告：
在这个被大厂垄断、被 AI 噪音填满的世界里，我们依然可以凭借几百 K 的预算、五六个人的小团队，用对技术的极致纯粹，造出一把劈开混沌的利剑。
如果你也曾在这个庞大的系统工程世界里感到过疲惫与迷茫，不妨去试一试 Zig 吧。那是一片没有资本催促、没有 AI 噪音的，属于纯粹程序员的乌托邦。
资料链接：https://www.youtube.com/watch?v=iqddnwKF8HQ
✍️ 今日开放讨论
在这个几乎所有人都疯狂拥抱 AI 编程（Claude Code/ Codex /Antigravity Cli等）的时代，Zig 官方明确拒绝 AI 生成的 PR。你认为是 Andrew Kelley 过于“迂腐”，还是他在守护开源软件最核心的“导师制与高质量传承”？
欢迎在评论区留言，分享你对“AI 垃圾代码”以及系统编程语言发展趋势的看法！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-06-11 08:18:00
本文永久链接 – https://tonybai.com/2026/06/11/writing-idiomatic-go-make-you-better
大家好，我是Tony Bai。
在技术圈里，Go 语言（Golang）一直扮演着一个特立独行、甚至有些“格格不入”的角色。
如果你去问一个写 Java、Python、TypeScript 或是 C++ 的程序员对 Go 的第一印象，得到的回答大概率是：“无聊”、“简陋”，以及无处不在的 “冗余样板代码（if err != nil）”。它没有优雅的异常捕获机制，早期坚决不引入泛型，更把面向对象最核心的“类继承”给无情斩断了。
然而，在技术社区 Reddit 的 r/golang 板块中，一个极其深刻的问题引发了全网热议：“写地道的 Go 语言（Idiomatic Go），是否让你成为了一个更好的整体开发者？”
令人惊讶的是，那些在业界摸爬滚打多年的大厂架构师、技术主管和多语言老兵们，几乎给出了高度一致的肯定回答。
Go，这门刻意在语法上“自我阉割”、拒绝一切魔法和花哨抽象的语言，究竟是如何反向输出、重新格式化一个程序员的底层智力结构的？在这篇文章中，我们就一起来盘点一下。
每个刚开始写 Go 的开发者，最难以忍受的就是地道 Go 语法里近乎强迫症的错误处理：
val, err := DoSomething()
if err != nil {
return fmt.Errorf("failed to do: %w", err)
}
很多人抱怨：“为什么我非得在每一行可能出错的代码下面，写这三行废话？”
但在 Reddit 的高赞回复中，一个资深开发者从系统设计的层面一针见血地指出了真相：“基于异常（Exception-based）的语言，给我们制造了一种‘异常被完美控制’的幻觉。这其实是极不负责任的。”
在 Java 或 Python 中，当你调用一个可能失败的函数时，你的业务控制流是隐式的。你抛出一个异常，寄希望于上层某个魔妙的 try-catch 块能抓住它。
但实际情况往往是：开发者为了代码的“清爽”，假装看不见潜在的失败，直到生产环境爆出未捕获的运行时异常（Runtime Exception），导致系统崩溃。
而地道的 Go 语言通过返回 (Value, error) 的双元组，逼迫你和错误进行面对面的正面刚：
许多开发者表示，在适应了 Go 的显式错误处理后，他们回去写 Python 或 TypeScript 时，再也不敢盲目依赖全局异常捕捉了。他们会主动用元组（Tuple）或类似 Result 的结构，在调用点显式解包。这种对错误的敬畏和就地处理的工程意识，是成为高级后端架构师的第一步。
很多程序员在拥有了 3 到 5 年的开发经验后，极易患上一种名为“过度设计（Over-engineering）”的职业病：一看到业务需求，本能地就想套用几十种设计模式、建十几层继承树、引入各种高级的元编程和装饰器魔术。
而 Go，是这种“架构妄想症”的特效解毒药。
一位Reddit 用户分享了他的经历。在写了一段时期的 Go 之后，他回过头去写 Python：
“天啊，我突然发现有 5 种完全不同的方法去遍历和操作一个数组。我开始陷入无谓的选择困难和审美疲劳。我突然开始怀念 Go 那种‘只有一种最笨、最直接的写法’的无聊感。”
Go 语言在设计之初，就故意将语言特性压缩到了极致。它没有隐藏的控制流，没有神奇的操作符重载，没有复杂的类继承。
这种“无聊”逼迫你放弃在代码形式上炫技，转向思考最本质的问题：
写好地道的 Go 要求你学会“自我克制”。当你学会在编译器的安全网中，用最平铺直叙的代码去平复系统的复杂性时，你才真正跨过了从“写代码的泥瓦匠”到“管理复杂度的工程师”的门槛。
面向对象（OOP）的“多重继承”和“深层父子类”是无数中大型项目腐烂的温床。当你修改了一个顶层父类的方法时，你根本无法预知下面几十个子类会发生怎样灾难性的崩塌。
Go，彻底斩断了这条锁链。它创造性地采用了隐式接口（Structural Subtyping/鸭子类型）。
Go 社区有一句广为人知的黄金法则：“Accept interface, return struct.”（接受接口，返回结构体）。
这一原则在 Reddit 社区中被无数开发者奉为圭臬：
这种设计迫使你放弃设计复杂的“分类学（Taxonomy）”层级，转而像拼装乐高积木一样，用 “组合（Composition）” 的思路去重组系统。
在 Go 中，数据（Struct）和行为（Methods）是彻底分离的。没有 giant Class 树，只有扁平的、通过隐式接口拼装在一起的松耦合组件（Ports & Adapters）。这种“六边形架构”思维一旦融入你的脑海，你再去写任何其他语言，都会自然而然地写出极度清爽、极易重构的代码。
在 Reddit 讨论中，最让人产生共鸣的一句话是：
“Idiomatic Go was intentionally designed to make code easy to read for the next developer, not easy to write for the current one.”（地道的 Go，其设计的首要目标是让代码便于下一个开发者阅读，而不是为了让当前的开发者写得爽。）
很多年轻程序员总觉得“越精妙、越难懂、别人都看不懂的代码”才代表高水平。但当你真正经历过生产环境的毒打，半夜三点被报警电话叫醒去 debug 一个无人能懂的“聪明代码”时，你才会明白：可预测性（Predictability）和可读性（Readability）才是衡量一个程序员职业素养的终极指标。
Go 语言通过它的各种限制，强行把大家的代码拉到了同一个频道上。
它逼迫你交出在代码里展示智力优越感的方向盘，让你学会在业务逻辑的深度、数据的流向和工程的健壮性上去寻找真正的技术挑战。这种在软件工程层面的“祛魅”与成熟，正是地道的 Go 给予我们最珍贵的礼物。
回到最初的问题：写地道的 Go 语言，是否能让你成为了一个更好的开发者？
答案是毫无疑问的。
Go 语言就像是一套高标准的“驾驶训练模拟器”。它通过在内存安全、并发模型、依赖管理和错误处理上的硬性规则，逼迫你戒掉所有在其他高级语言中惯出来的“坏毛病”。
它强迫你直面系统失败，强迫你用组合去代替继承，强迫你把简单和可维护性放在首位。
当你完成了这场认知洗礼，重新格式化了自己的大脑之后，你会发现，即便有一天你离开了 Go 去写 C++、Java 或 Python，你写出来的代码也变得比以前更干净、更清晰、更易重构。因为你已经学会了像一个真正的软件工程师一样去思考问题。
资料链接：https://www.reddit.com/r/golang/comments/1tza18e/did_writing_idiomatic_go_made_you_a_better/
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-06-10 08:23:34
本文永久链接 – https://tonybai.com/2026/06/10/lets-encrypt-adopts-mtcs-preparing-for-post-quantum-security
大家好，我是Tony Bai。
当你在浏览器地址栏看到那把绿色的小锁，或是敲下 https:// 时，你正在被人类历史上最伟大的密码学基础设施——Web PKI（公钥基础设施）保护着。
长久以来，这套系统的基石是 RSA 和 ECDSA 签名算法。它们精巧、高效，扛住了互联网过去几十年的爆炸式增长。然而，一场风暴正在逼近。
随着量子计算机的发展，悬在所有密码学家头顶的“达摩克利斯之剑”——CRQC（密码学相关的量子计算机），其倒计时正在被各大科技巨头疯狂拨快。
近日，全球最大的免费 HTTPS 证书颁发机构 Let’s Encrypt 发布了一篇声明：《Let’s Encrypt 的后量子未来》。在这份声明中，Let’s Encrypt 不仅拉响了后量子时代的警报，更抛出了一个足以重塑整个互联网底层通信逻辑的终极杀手锏：MTCs（Merkle Tree Certificates，默克尔树证书）。
为什么传统的 RSA 和 ECDSA 会被淘汰？为什么直接换上标准的后量子算法会导致整个互联网“网速倒退”？今天，我们就来深度硬核拆解 Let’s Encrypt 这场惊心动魄的“后量子求生战”。
在讨论后量子密码学（Post-Quantum Cryptography, PQC）时，我们通常要区分两个概念：加密（Encryption / 密钥交换）和认证（Authentication / 签名）。
过去几年，业界对后量子“加密”极为焦虑。原因很简单：“现在收集，以后解密（Harvest now, decrypt later）”。攻击者现在就可以把你加密的流量存进硬盘，等 10 年后量子计算机成熟了，再拿出来暴力破解。因此，像 Google、Cloudflare 这样的巨头早已在各大浏览器和服务器中部署了混合后量子密钥交换算法（如 X25519MLKEM768）。
相比之下，“认证”似乎没那么紧迫。
因为证书签名的作用是证明“我是我”。要伪造一个服务器身份，量子计算机必须在 TLS 握手的几百毫秒内实时（in real time）伪造出一个签名，而不能“事后追溯”。因此，大家都觉得，只要 CRQC 还没造出来，签名就是安全的。
但这种安全感正在被撕裂。
警报拉响了，留给 Web PKI 生态转身的时间，已经从“未来某天”缩短到了“迫在眉睫”。
面对量子威胁，最直接的思路就是：既然 RSA 和 ECDSA 不顶用了，咱们直接把它们替换成 NIST（美国国家标准与技术研究院）最新发布的后量子标准算法 ML-DSA 不就行了吗？
答案是：不行！因为太胖了。
Web PKI 是全球部署环境最复杂的系统之一。在一次典型的 TLS 握手（就是你建立 HTTPS 连接的那一瞬间）中，服务器需要向你的浏览器发送大概 5 个签名和 2 个公钥。
让我们来看看这场“体积灾难”的对比（参考官方给出的图表）：
如果我们在现有的 Web PKI 架构下，简单粗暴地把所有的 ECDSA 替换成 ML-DSA，那么单次 TLS 握手的数据量将直接突破 10 KB（10,000 字节）大关！
这会带来什么毁灭性的后果？
Cloudflare 的硬核研究表明，当 TLS 握手体积膨胀到这个规模时，由于 TCP 拥塞窗口机制和网络 MTU 的限制，大量真实世界的网络连接将直接失败（Fail），而幸存下来的连接也会遭遇严重的延迟。
试想一下，全球数十亿台低带宽的物联网设备、偏远地区的手机，在每一次发起 HTTPS 请求时都要被迫下载十几 KB 的“肥胖”证书。这种为了“防御一个尚未出现的威胁”而牺牲全人类网络体验的做法，在工程上是绝对不可接受的默认设定。
在绝望之中，Let’s Encrypt 和一众硅谷巨头找到了一个极其优雅且疯狂的解法——Merkle Tree Certificates（MTCs）。
这个机制不仅解决了签名体积过大的问题，还顺手重塑了证书透明度（Certificate Transparency, CT）的底层逻辑。
在现有的 Web PKI 中，CA（证书颁发机构）在签发证书时，会对每一张证书单独进行一次签名。
而 MTCs 彻底颠覆了这个逻辑：
CA 不再对单个证书签名，而是把一段时间内（比如一个小时）要签发的所有证书，收集起来构建成一棵 Merkle Tree（默克尔树）。然后，CA 只需要用后量子算法（如 ML-DSA），对这棵树的树根（Root）进行一次唯一的签名。
既然没有单独的签名了，你的浏览器怎么知道你访问的网站证书是合法的呢？
这里利用了默克尔树的密码学奇迹——包含证明（Inclusion Proof）。
浏览器（或客户端）会在后台定期更新 CA 发布的“树根”信息（被称为 Landmarks）。当浏览器访问服务器时，服务器只需要提供一条从自己这片“叶子”走到“树根”的路径（包含证明）。
因为哈希算法生成的包含证明（如 SHA-256）体积非常小（通常只有几百字节），所以在这种常见情况（Common Case）下，一次 TLS 握手的认证数据：
1 个短小精悍的包含证明 + 1 个公钥 + 0 个笨重的后量子签名！
在传统的 PQ（后量子）架构下，开销高达 7,260 字节；而采用了 MTCs 后，瞬间被压缩到了 736 字节，性能甚至直逼现有的传统算法。
这个体积甚至比今天基于 RSA/ECDSA 的传统握手还要小！这种从“胖子”变“瘦子”的降维打击，正是 MTCs 被奉为救星的根本原因。
现有的证书生态里，证书透明度（CT Logs）是一个事后缝合的“补丁”：CA 签发证书后，需要把它记录到一个单独的 append-only 日志系统中，并把签名附在握手数据里。
但在 MTCs 的世界里，“这棵默克尔树本身，就是那个追加日志（Append-only Tree）”！
由于每一张证书都必须存在于默克尔树中才能生效，这意味着没有任何一张 MTCs 证书可以脱离监控而秘密存在。CT 机制被完美、原生在地融入了底层协议中。
这对于 Let’s Encrypt 来说可谓是得心应手，因为他们自 2019 年以来就一直在维护基于底层树数据结构的 CT 日志，技术储备早已拉满。
Let’s Encrypt 宣布，他们正计划在 2026 年末提供 MTCs 的测试环境（Staging），并在 2027 年正式推向生产环境（Production）。
这是 Web PKI 历史上一次规模浩大的“基础设施更换手术”。作为开发者和系统运维人员，这几个关键点你必须立刻了解：
作为服务器的运营者，你现在必须立刻行动：检查你的 Web 服务器（如 Nginx, Envoy, Caddy等）和操作系统配置，确保已经开启了混合后量子密钥交换（如 X25519MLKEM768）。 所有的主流浏览器现在都已经支持它，这是你今天能做的 ROI 最高的安全升级！
从 2013 年 Let’s Encrypt 创立至今，他们始终秉持着一个信念：安全应该是全球每个人都能平等获取的基础权利。
从推动全网 HTTPS 普及，到如今在量子威胁的阴影下，不惜重构庞大底层架构以推行 MTCs，这场无声的战役，不仅是算力与算法的博弈，更是人类为了守护数字世界的信任基石，所进行的一次史诗级防守反击。
达摩克利斯之剑已经落下，但得益于这些密码学极客的疯狂努力，当风暴真正来临的那一天，我们浏览器的左上角，那把绿色的小锁，依然会坚定地亮起。
资料链接：https://letsencrypt.org/2026/06/03/pq-certs
今日开放讨论：
当 MTCs（默克尔树证书）将证书透明度（CT）彻底融入底层结构时，你认为它会对现有的防火墙流量审计（如企业内网对 TLS 的中间人解密审计）带来哪些阻碍和变化？
欢迎在评论区分享你的安全架构洞察，我们一起探讨后量子时代的网络防线建设！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
2026-06-10 08:21:32
本文永久链接 – https://tonybai.com/2026/06/10/the-story-of-cpp
大家好，我是Tony Bai。
如果将人类现代软件工业比作一部庞大的机器，那么支撑其运转的最核心骨架中，无疑很大一部分由C++支撑。从你手中的智能手机操作系统、每天刷的短视频推荐引擎、华尔街每秒百万次的高频交易系统，到驱动大语言模型（LLM）的底层算力矩阵，C++ 几乎无处不在。
在过去的 40 年里，这门语言一次次被宣布“濒临死亡”，却又一次次浴火重生。它被称为“弗兰肯斯坦的怪物”，被无数程序员诅咒过其令人发指的复杂性。但即便在如今 Rust 和 Go 等现代语言强势围剿的今天，C++ 依然稳坐系统级编程的王座。
近日，一部名为《The Story of C++: The World’s Most Consequential Programming Language》（C++ 官方纪录片）在 YouTube 上引起了巨大轰动。这部长达近两小时的纪录片，首次召集了包括 Bjarne Stroustrup（C++ 之父）、Alexander Stepanov（STL 之父）在内的一众 C++ 核心缔造者，向世人揭开了这门语言背后那些鲜为人知的妥协、背叛与权力斗争。
更精彩的是，在海外技术社区 Reddit 的 r/cpp 板块中，这部纪录片引发了无数大厂老炮和编译器极客的热烈讨论，通过将纪录片的官方叙事与社区的“野史”拼凑在一起，我们看到了一部远比代码本身更惊心动魄的技术史诗。
时间倒回 1979 年。彼时的贝尔实验室（Bell Labs）是全球计算机科学的“麦加圣地”，Ken Thompson和Dennis Ritchie 在这里创造了 C 语言和 Unix 系统。整个世界都沉浸在 C 语言那种贴近硬件、极致简洁的暴力美学中。
就在此时，一个名叫 Bjarne Stroustrup 的丹麦年轻人来到了贝尔实验室。他需要编写复杂的分布式系统模拟器，很快便发现，C 语言那套基于“函数与指针”的过程式编程，在面对巨大且复杂的系统时，就像是在用石器时代的工具建造摩天大楼——代码极易失控，且难以复用。
于是，他做了一个极具叛逆性的决定：他要在 C 语言的基础上，引入“类（Classes）”的概念。 这就是最初的“C with Classes”。
Bjarne 的初衷极其务实：他不想重新发明轮子，他只想让现有的 C 程序员能够稍微优雅一点地写代码。 因此，他定下了一条死命令：C++ 必须 100% 兼容 C 语言。
在 Reddit 的讨论中，一位资深 C++ 工程师指出：“C++ 之所以能在早期存活下来，唯一的理由就是它能够与海量的 C 语言头文件无缝对接。” 这条与 C 的“血脉绑定”，成为了 C++ 能够迅速占领企业级市场的最强杀手锏，但也为它日后的无底洞复杂性和编译期灾难埋下了最深远的隐患。
如果说 Bjarne 给了 C++ 骨架，那么真正赋予 C++ 灵魂的，是另一个极具争议的天才：Alexander Stepanov。
在 90 年代初，面向对象编程（OOP）如日中天。所有人都在沉迷于画继承树、搞多态。但 Stepanov 对此嗤之以鼻。他认为，将数据结构和算法强行绑定在对象里，是一种“极度低效且愚蠢的数学谬误”。
他提出了一种名为“泛型编程（Generic Programming）”的思想：算法应该独立于数据结构之外，通过一种叫“迭代器（Iterator）”的桥梁连接。
这就是后来名震天下的 STL（标准模板库）。
在纪录片中，最戏剧性的一幕发生在 1993 年的 C++ 标准委员会上。当 Stepanov 第一次将庞大且极其复杂的 STL 提案摆在委员会面前时，遭到了全场的群嘲与抵制。
“这太庞大了！这太疯狂了！这简直是在强奸编译器！”大佬们纷纷摇头。
此时的 C++ 委员会，正沉浸在由微软、IBM 等科技巨头把持的“门派斗争”中，没有人愿意为这种学术界的“屠龙术”买单。
在生死存亡之际，是 Bjarne 站了出来。为了让 STL 能够活下来，Bjarne 甚至不惜“扭断了自己亲生孩子的手臂”。
一位Reddit 用户分享了一段极其硬核的野史：“听到 Bjarne 承认为了让 STL 能在早期的 Cfront（C++ 编译器前置工具）上编译通过，他强行修改了 C++ 的语言规则，甚至导致了著名的 Cfront 2.0 bug，这简直太搞笑了！”
最终，在 Bjarne 的权力背书下，STL 以极其微弱的优势通过了委员会的投票。这一决定，彻底改变了现代软件工业的走向。没有 STL 提供的 Vector、Map 和极度优化的泛型算法，后来的谷歌、亚马逊和高频交易公司根本无法在 C++ 上构建起支撑亿万级流量的系统。
正当 C++ 在系统底层攻城略地时，外部的绞杀战开始了。
2000 年前后，C++ 迎来了它生命中最黑暗的“冰河期”。在 Reddit 上，大厂老炮们对这段历史记忆犹新：
当时的 C++，就像是一个垂暮的老人：没有包管理器、跨平台编译像一场噩梦、ABI（应用程序二进制接口）地狱让人抓狂。甚至有人提到了一篇著名的早期新闻标题：“The Decline of C++?（C++ 的衰落？）”
更致命的是，C++ 标准委员会（WG21）在这个时期陷入了长达十年的“难产”。各大编译器厂商（尤其是微软的 MSVC）为了各自的商业利益互相扯皮。
在 Reddit 的帖子中，现任 MSVC STL 开发者的 STL 本尊亲自下场“辟谣”与爆料：
当时有很多开发者抱怨微软试图“破坏”STL（因为微软在 STL 里加入了极度拖慢性能的迭代器调试代码 _SECURE_SCL）。STL 大神解释道：“*微软并没有试图破坏 STL，这纯粹是出于对安全性的妥协，而在 2000 年代，由于编译器团队对 C++ 底层模板的理解不足，导致了糟糕的实现。*”
无论如何，在这漫长的十年里（C++98 到 C++11 之前），C++ 停滞不前。这段历史在官方纪录片中被轻描淡写地带过，但在社区看来，这是 C++ 被巨头资本裹挟、险些丧命的耻辱时代。
就在所有人都以为 C++ 将退化为一门“只配用来写驱动”的边缘语言时，C++11 横空出世。
这绝对是编程语言史上最伟大的一次“续命”。C++11 引入了 auto、智能指针（Smart Pointers）、Lambda 表达式以及多线程支持。它仿佛将一辆生锈的老爷车，直接改装成了核动力飞船。
Reddit 上的一位开发者感叹道：“如果你没有经历过在 C++11 之前，仅仅是想要实现一个跨平台的多线程逻辑，就能触发各种未定义行为（UB）的时代，你就无法理解我们现在拥有的现代 C++ 有多么幸福。”
此时，硅谷的巨头们也终于醒悟。随着摩尔定律的逐渐放缓（单核 CPU 的免费午餐结束了），亚马逊、谷歌、Meta 以及高频交易巨头 Hudson River Trading（HRT）发现：要想在服务器账单上省下数千万美元，要想让延迟降低到微秒级，只有一条路可走——回归 C++。
从 C++11 开始，标准委员会终于恢复了活力，确立了每三年发布一个新标准（C++14, C++17, C++20…）的铁律。
纪录片中展示了今天 C++ 标准委员会的盛况：从最初的几十人，变成了现在动辄数百人的庞大机构。但这同时也带来了新的诅咒：过度设计与特征膨胀（Feature Bloat）。
纪录片以一种充满希望的基调收尾，特别提到了即将到来的 C++26 及其杀手级特性：静态反射（Static Reflection）。
但在 Hacker News 和 Reddit 上，那些每天深陷在 C++ 屎山代码中的一线架构师们，却显得远没有那么乐观。
1. 缺失的拼图：为什么官方不敢提 Boost？
眼尖的社区极客指出，这部宣称是“官方历史”的纪录片，竟然对 Boost 库 只字未提！要知道，在 C++ 停滞的十年里，是 Boost 库（包含大量实验性的元编程和现代特性）几乎凭借一己之力撑起了 C++ 的生态，并孵化了 C++11 的大部分新特性。社区猜测，这背后可能涉及到 Boost 基金会与 C++ 标准委员会之间复杂的权力斗争与未解恩怨。
2. 基础设施的荒漠：构建工具与包管理器之殇
在 Reddit 上，超过一半的火力集中在一个最朴素的痛点上：C++ 至今没有一个像样的官方包管理器。
当你用 Go 或 Rust 开发时，go get/install 或 cargo install 就能优雅地解决一切。但在 C++ 中，为了集成一个第三方库，你需要聘请一个拥有“博士学位”的 CMake 工程师，在 vcpkg、Conan、Bazel 之间痛苦挣扎，还要处理无穷无尽的 ABI（应用程序二进制接口）冲突。
一位大厂架构师绝望地写道：“标准化不应该强迫企业妥协，但现有的三大包管理器，导致了生态的极端割裂。C++ 真正的问题不在于语言层面，而在于其糟糕透顶的工程工具链体验。”
3. 碳（Carbon）与锈（Rust）的围剿
如今，谷歌推出了试图平替 C++ 的 Carbon 语言，而白宫甚至在安全报告中公开呼吁开发者放弃 C/C++，转向内存安全的 Rust。
面对如此巨大的压力，C++ 能够挺过下一轮大洗牌吗？
答案或许依然是肯定的。因为 C++ 早就超越了一门编程语言的范畴，它已经成为了人类数字文明的基础物理法则之一。 那些数以百亿计的遗留代码，那些经历了三十年实战检验的高频交易系统，那些与硬件深度绑定的 GPU 调度矩阵，是不可能在十年内被 Rust 或 Go 完全重写的。
《The Story of C++》不仅是一部纪录片，它是一面镜子。它照出了人类在构建庞大数字帝国时，那种充满妥协、混乱却又无比顽强的工程精神。
C++ 的世界里没有完美的乌托邦。正如 Bjarne Stroustrup 那句最著名的名言：
“世界上只有两种编程语言：一种是人们天天在抱怨的语言，另一种是根本没人用的语言。”
而 C++，无疑是被抱怨得最狠，却又永远无法被抛弃的那一个。
资料链接：
今日开放讨论：
作为开发者，你认为 C++ 目前最大的痛点是由于它必须保持与 C 的后向兼容（Backwards Compatibility），还是因为它糟糕的构建和包管理工具？在 AI 和 Rust 崛起的时代，你会建议新人继续深入学习 C++ 吗？
欢迎在评论区留下你的观点，我们一起探讨系统级编程的未来！
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！
我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：
衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
© 2026, bigwhite. 版权所有.
