标签 Rust 下的文章

当 Go 还在追求极简时,C++ 26 却又加了四大“史诗级”新特性

本文永久链接 – https://tonybai.com/2026/03/31/go-minimalism-vs-cpp26-epic-new-features

大家好,我是Tony Bai。

在这个 Go、Zig 等“小而美”新语言颇受青睐的时代,如果你去技术社区里问一句:“C++ 这门语言怎么样?”

你大概率会得到一堆充满戏谑的回答:“太复杂了,别学”、“从入门到放弃”、“面试造火箭,工作拧螺丝”。

C++,这门诞生于上世纪 80 年代的编程语言,似乎早已被贴上了“老旧、臃肿、极其反人类”的标签。在很多新生代开发者眼里,它就像一头步履蹒跚的史前巨兽,理应被时代所淘汰。

但就在前天(2026年3月29日),这头“史前巨兽”不仅没有倒下,反而亮出了它那足以撕裂天空的獠牙。

C++ 标准委员会主席、C++ 界的“教父级”人物 Herb Sutter 亲自在博客上宣布:C++26 标准的技术工作,已正式完成!

Herb Sutter 还用极其兴奋的口吻将其定义为“自 C++11 以来最具冲击力的一次发布”。而这次更新的核心,是四个被他称为“Fab Four”(神奇四侠)的史诗级新特性。

当我耐着性子看完全部内容后,我脑子里只剩下四个字:叹为观止。

当 Go 语言的开发者还在为“是否要给语言增加一个三元表达式”,或泛型方法而激烈辩论时,C++ 却反其道而行之,给自己又加装了四门“宇宙级”的重型武器。这到底是 C++ 吹响的绝地反击号角,还是压垮骆驼的最后一根稻草?

今天,我们就来硬核扒开 C++26 这四大“金刚”,看看它们到底有多强,以及它们将如何影响将来程序员对编程语言的选择。

第一门重炮:反射(Reflection)——“代码生成代码”的终极魔法

Herb Sutter 将反射放在了四大特性之首,并称之为“自模板(Templates)发明以来 C++ 最重要的升级”。

什么是C++ 的反射?简单来说,就是让代码在编译期拥有了“自我审视”和“自我创造”的能力。

在 C++26 之前,如果你想实现一个通用的 JSON 序列/反序列化库,你必须写大量重复的模板代码,或者用各种丑陋的宏来“欺骗”编译器。

但在 C++26 中,你可以像这样写出充满“神性”的代码(代码示意):

这段代码,在编译的时候就能根据编译时的输入(test.json)自动分析JSON构造,并生成编译时用于计算的一个新类型。这在 Go 语言里,需要借助 reflect 包在运行时(Runtime)以牺牲性能为代价才能做到。而 C++,直接在静态编译期(Compile-time)零成本搞定了!

Herb Sutter 将其形容为“C++ 的十年火箭引擎”。这意味着,未来 C++ 社区将涌现出无数极其强大、但又极其复杂的元编程(Metaprogramming)库。C++ 的学习曲线,将再次被拉到一个新的高度。

第二道防线:内存安全(Memory Safety)——“只需重编,安全自来”

如果说反射让 C++ 的上限变得更加遥不可及,那么内存安全的提升,则是 C++ 在向 Go 和 Rust 的核心优势区发起的正面冲锋。

C++ 常年被诟病的核心痛点是什么?内存不安全。悬垂指针、未初始化变量读取(导致未定义行为)……这些噩梦困扰了 C++ 程序员几十年。

C++26 给出了一个极其诱人的承诺:你的老代码一行都不用改,只要用 C++26 模式重新编译,就能自动获得大幅度的安全提升!

这主要来源于两个方面的改进:

  1. 消灭未初始化变量的 UB:在 C++26 中,读取未初始化局部变量不再是“未定义行为(Undefined Behavior)”。这意味着困扰无数新手的、极其诡异的程序崩溃,将成为历史。
  2. “加固”的标准库:Google 和 Apple 已经将它们内部经过“加固(Hardened)”的标准库实现贡献给了 C++26。这意味着,当你使用 std::vector, std::string 等容器时,大量的边界检查会自动开启。

Herb Sutter 引用了 Google 的内部数据:

“仅在 Google,这项技术就已经修复了超过 1000 个 Bug,预计每年可以预防 1000 到 2000 个新 Bug 的产生,并将整个生产环境的段错误(Segfault)率降低了 30%。”

这简直是在对 Go 说:“你用 GC 换来的那点可怜的安全性,我 C++ 现在也能做到了,而且依然是零成本的!”

第三把利剑:契约(Contracts)——代码里的“法律条文”

如果你写过 Go,你一定对满屏的 if param == nil { return errors.New(…) } 感到厌烦。这种防御性编程,虽然有效,但极其啰嗦。

C++26 正式引入了语言级的契约编程

你可以像签合同一样,为你的函数制定严格的法律条文:

这些 pre 和 post 是编译器和运行时可以理解并强制执行的“法律”。如果调用者违反了前置条件,程序可以在开发阶段就立刻崩溃并给出明确的报错,而不是等到数据被污染后才在某个奇怪的地方爆炸。

虽然 Go 社区也在讨论类似的泛型断言,但 C++26 已经先行一步,将其做成了语言标准。

第四个引擎:std::execution——C++ 的“亲儿子”协程模型

在 C++20 中,虽然引入了 co_await 协程,但它只是一个语法糖,并没有提供一个统一的调度框架。

C++26 终于补上了这块短板,正式推出了 std::execution,也被称为 Sender/Receiver 模型

这是一个极其强大、统一的异步模型框架。它让你能以一种声明式的方式,去描述、组合和调度复杂的并发任务流。

下面是一段使用std::execution的代码示例:

// This is an example of a custom algorithm for starting work
// without allocations. This algorithm is also available in
// <exec/start_now.hpp>. (Users that don't write custom sender
// algorithms will not need to use receivers or call connect
// or start.)
template <stdexec::sender_in<stdexec::empty_env> Sender>
struct start_now {
  start_now(Sender sndr)
    : _op(stdexec::connect(std::move(sndr), _sink_rcvr())) {
    stdexec::start(_op);
  }
private:
  // start_now is implemented in terms of this custom receiver,
  // which is used to discard Sender's results.
  struct _sink_rcvr {
    using receiver_concept = stdexec::receiver_t;
    void set_value(auto&&...) noexcept {}
    void set_error(auto&&) noexcept {}
    void set_stopped() noexcept {}
  };
  stdexec::connect_result_t<Sender, _sink_rcvr> _op;
};

int main() {
  // A run loop is a fifo queue of work and a loop to execute the
  // work. It needs to be driven by calling its .run() member fn.
  stdexec::run_loop ctx;
  auto event_loop = ctx.get_scheduler();

  // Create two tasks that cooperatively multitask.
  auto task1 = stdexec::just()
             | stdexec::then([]{ std::puts("hello from task 1! suspending..."); })
             | stdexec::continue_on(event_loop) // suspend
             | exec::repeat_n(5)
             | stdexec::then([]{ std::puts("task 1 is done!"); });

  auto task2 = stdexec::just()
             | stdexec::then([]{ std::puts("hello from task 2! suspending..."); })
             | stdexec::continue_on(event_loop) // suspend
             | exec::repeat_n(8)
             | stdexec::then([]{ std::puts("task 2 is done!"); });

  // Start both tasks. This enqueues them for execution on the run loop.
  auto op1 = start_now(stdexec::start_on(event_loop, std::move(task1)));
  auto op2 = start_now(stdexec::start_on(event_loop, std::move(task2)));

  ctx.finish(); // tell the run loop to stop when the queue is empty
  ctx.run();    // tell the run loop to start executing work in the queue
}

这可以被看作是 C++ 对 Go 的 Goroutine + Channel 模型,以及 Rust 的 async/await + tokio 模型的终极回应。

它让 C++ 开发者第一次拥有了一套语言原生的、能够轻松编写“无数据竞争(Data-race-free by construction)”并发程序的“亲儿子”工具。

小结:一场没有退路的豪赌

反射、安全、契约、并发。C++26 的这四大金刚,每一个都足以在其他语言中引发一场大地震。

我们看到的是一头苏醒的巨兽。它没有选择像 Go 那样“断舍离”,也没有像 Rust 那样“偏执于安全”,而是极其贪婪地选择了:“我全都要!”

它既想要极致的表达能力和零成本抽象(反射、模板),又想要与 Rust 媲美的内存安全(加固标准库),还想要不输 Go 的并发表达力(std::execution)。

C++26 给老兵们提供了前所未有的强大武器,但也把本就陡峭的学习曲线,又向上抬升了一个令人惊叹的高度,宇宙第一复杂的编程语言,实至名归!

当 Go 的开发者还在为“是否要加个三元表达式”而争论不休时,C++ 已经头也不回地奔向了“万神殿”。

或许,编程语言的终局,真的不是“大一统”,而是“两极分化”:一极是像 Go 一样追求极致简单的“工程师语言”;而另一极,则是像 C++ 这样,专为那 1% 的、追求极致性能和控制力的“宗师级”开发者准备的、布满荆棘的封神之路。

C++26,欢迎来到神的世界,也欢迎来到神的炼狱。

参考资料

  • https://herbsutter.com/2026/03/29/c26-is-done-trip-report-march-2026-iso-c-standards-meeting-london-croydon-uk/
  • https://herbsutter.com/2025/06/21/trip-report-june-2025-iso-c-standards-meeting-sofia-bulgaria/
  • https://herbsutter.com/2024/07/02/trip-report-summer-iso-c-standards-meeting-st-louis-mo-usa/
  • https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2996r13.html
  • https://www.youtube.com/watch?v=7z9NNrRDHQU
  • https://www.youtube.com/watch?v=oitYvDe4nps

今日互动探讨:

看完 C++26 的这四大“神仙”特性,你是感到兴奋,还是感到了深深的绝望?你觉得 C++ 的这种“大而全”的演进路线是对的,还是 Go 的“小而美”更代表未来?

欢迎在评论区分享你的看法!


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

Rust 核心团队大吐苦水:求求你们别再用 AI 提交“垃圾 PR”了!

本文永久链接 – https://tonybai.com/2026/03/26/rust-project-perspectives-on-ai

大家好,我是Tony Bai。

在这个大模型狂飙突进的时代,只要在推特或者掘金上刷一刷,你几乎每天都能看到这样的“成功学”分享:

“我是如何用 Claude Code + 4.6 Sonnet 在一天内向知名开源项目提交了 10 个 PR 的!”

“用 Cursor 混 GitHub 绿点,原来这么简单!”

这些利用 AI 工具轻松突破“开源门槛”的开发者们,正在享受着前所未有的技术平权红利。

但你有没有想过,站在这些开源项目背后的核心维护者(Maintainers)们,正在经历着怎样的地狱?

Go核心团队拒绝 AI 署名,为AIGC 时代的Go项目划下的“工程红线”后,前不久,Rust 项目的核心开发者、语言设计团队负责人 Niko Matsakis 在内部发起了一场长达数周的“大摸底”,旨在收集 Rust 核心贡献者和维护者们对于 AI 辅助编程的真实看法。

目前阶段性地汇总出的这份长达 20 多页的内部讨论纪要,犹如一枚深水炸弹,撕开了“AI 编程繁荣”背后的残酷真相:毫无节制的 AI 生成代码,正在不可逆转地榨干 Rust 核心团队的精力,甚至将开源社区推向崩溃的边缘。

今天,我们就来扒开这份极其硬核的内部讨论,看看在这个世界上一贯严谨、对代码质量要求极高的社区里,顶级的Rust工程师们是如何看待、抵制、甚至反制 AI 编程的。

当 AI 沦为“盲目自信”的催化剂

在很多人的幻想中,AI 是小白进阶的导师,是帮你看懂复杂底层源码的引路人。

但在 Rust 维护者们的眼里,绝大多数情况恰恰相反:AI 正在沦为某些开发者盲目自信的催化剂。

一位Rust贡献者一针见血地指出了问题所在:

“AI 给那些原本心怀愧疚、不敢随便提交低质量代码的人,盖上了一个‘官方批准’的假印章。对于那些处于‘达克效应(指能力欠缺的人产生虚幻的优越感)’状态的开发者来说,AI 简直就是一剂催化剂。它极大地膨胀了他们的自信,却严重削弱了他们真正的能力。”

在传统的开源世界里,“提交 PR”是一项极其庄重的工作。你需要阅读庞大的代码库,理解设计哲学,甚至要为了改一行代码而去推演上下文的几百个变数。这种“艰难的门槛”本身就是一种过滤机制。

但现在呢?

你只需要把报错信息扔给大模型或专门的编码智能体,比如Claude Code,它会生成一段看起来“极度合理”、语法看似“完美无瑕”的 Rust 代码。你连这行代码底层的生命周期(Lifetime)都没看懂,就欢天喜地地点了 git commit。

你以为你是在为开源做贡献,其实你只是把“寻找代码中细微致命毒药”的工作,无情地转嫁给了那些用爱发电的 Rust 维护者。

被“AI 传声筒”折磨到崩溃的维护者

如果说 AI 生成的代码只是质量差,那维护者大不了直接关闭 PR 就可以了。真正让 Rust 核心团队感到绝望甚至想要“退网”的,是那些把 AI 当作“传声筒”的贡献者。

让我们来看另一个让核心成员愤怒到使用加粗字体的真实案例:

“一些贡献者甚至充当起了审查者(Reviewer)和大模型之间的‘传声筒’!他们复制我提问的 Review 意见,扔给大模型,然后把大模型生成的胡言乱语直接复制回来回复我。看在上帝的份上,求求你们停下吧!我想强调,这极其令人抓狂。这是导致我极度倦怠(Burn out)的头号因素!

开源项目不仅仅是一堆冷冰冰的代码,它更是一个“人与人交流、碰撞、建立信任”的社区(正如 Peter Naur 在经典文章《Programming as Theory Building》中所言)。

当维护者满怀期待地与你讨论某个特性的底层设计时,你却用极其冗长、没有营养、甚至充满幻觉的 AI 废话来敷衍他们。这不仅是在浪费时间,更是在无情地践踏开源社区最宝贵的“信任契约”。

另一位Rust贡献者的控诉则充满了无奈:

“我完全不知道该怎么解决这个问题:‘没错,你很快就生成了一段看起来很合理的代码,但它在微妙的细节上完全是错的,而现在你正在浪费所有人的时间去排查它’。”

在没有 AI 的时代,分辨垃圾代码很容易;但在 AI 时代,大模型最擅长的,就是把垃圾包装成米其林三星的模样端给你。

全面封杀,还是“用魔法打败魔法”?

面对这群不知疲倦的“AI 水军”,Rust 核心团队该怎么办?

在这份内部文档中,关于“如何对待 AI”的讨论,呈现出了极其撕裂的两种极端:

极端一:道德洁癖与坚决抵制

一些拥有极客精神的老兵认为,目前所有的 LLM 都是建立在“盗窃版权数据”的基础上的。不仅如此,大模型的训练正在消耗极度恐怖的能源,甚至让那些本该关闭的煤炭发电厂死灰复燃,加剧气候危机。

对于这些开发者而言,在 Rust 中拥抱 AI,就是对开源精神的背叛,是“令人作呕的”。他们主张全面封杀 AI 提交,并要求所有贡献者必须证明其代码完全由人类编写。

极端二:承认现实,用魔法打败魔法

但现实是残酷的。Niko Matsakis 等负责人非常清楚:“潘多拉的魔盒已经打开,堵是堵不住的。”

既然无法阻止人们用 AI 写 PR,那就想办法用规则甚至用 AI 自身来防御 AI。

在这场激烈的讨论中,Rust 团队提出了几项极具参考价值的“防御性架构与策略”,值得每一个饱受 AI 代码折磨的团队学习:

  1. 引入“反垃圾邮件”级的审查门槛:不再一视同仁地对待所有 PR。建立类似“Web-of-Trust(信任网)”的机制。只有当你在社区里通过人类交互证明了你的能力(提交过 N 次高质量代码)后,你的 PR 才会被优先审核。对于那些上来就提交上千行完美格式代码的陌生账号,直接打入冷宫。
  2. 强制签署“反 AI 免责声明”:在提交 PR 时,强制要求作者勾选确认:“我完全理解我提交的每一行代码,并能亲自回答 Reviewer 的任何问题;我没有直接复制大模型的回复来敷衍维护者。” 如果一旦发现充当“AI 传声筒”,立即实施封禁。
  3. 以毒攻毒,引入 AI 门卫:既然你们用大模型批量生成 PR,那我们就用大模型来做“初筛”。在人类 Reviewer 看代码之前,先让 AI Agent 去自动扫描那些“看似合理实则荒谬”的逻辑漏洞,直接打回重做。

AI 狂欢下的“零付费”收割

在整份纪要中,最让我感到扎心的一段话,是关于“开源维护者生存现状”的拷问。

目前,像 OpenAI、Anthropic 这样的 AI 巨头,估值动辄千亿美元。它们的模型能写出越来越好的 Rust 代码,很大程度上是因为它们疯狂吸收了 Rust 社区十几年积累的心血。

然而,当这些估值千亿的公司推出“编程 Agent”,导致开源社区的维护工作量呈指数级爆发时,那些没日没夜帮这些“AI 垃圾代码”擦屁股的 Rust 核心维护者们,却拿不到一分钱的报酬!

一位核心成员悲愤地提议:

“也许我们应该直接去找那些 AI 公司(他们内部也在大量使用 Rust),要求他们出资赞助我们的维护者。虽然很多人在道德上抵制这些公司,但我依然希望拿他们的钱来养活我们的兄弟们。”

这就好比一家巨无霸外卖平台,每天把几十万份外卖倾倒在你的社区门口,然后让社区里那些没有工资的清洁工志愿者去疯狂打扫。

在 AI 巨头狂欢的盛宴下,开源世界的基石正在被悄无声息地榨干。

小结:退潮之后,谁在裸泳?

这份长达 20多 页的讨论,给所有沉浸在“AI 改变命运”幻觉中的开发者敲响了一记震耳欲聋的警钟。

不可否认,AI 确实是极其强大的工具。文档中也有不少成员承认,使用 AI 让他们感到了“赋能(Empowered)”,让他们能轻松搞定平时不愿意碰的繁琐文档和构建脚本。

但工具的强大,永远无法掩盖使用者的平庸。

当你可以用 Claude Code 在 10 秒内生成一段精妙的多线程 Rust 代码时,请记住:

只有当你真正懂所有权(Ownership)、懂借用检查(Borrow Checker)、懂底层内存布局,并且能在发生诡异 Panic 时独立完成 Debug 的那一刻,这段代码才真正属于你。

否则,你不过是 AI 巨头商业版图上,一个毫无感情的、廉价的“代码搬运工”。

不要用战术上的(生成代码)勤奋,去掩盖战略上的(底层认知)懒惰。

在代码生成的迷雾中,保持清醒的头脑,去深钻那些 AI 无法替代的系统级设计思维和底层工程哲学,才是我们在大模型时代唯一的生路。

资料链接:https://nikomatsakis.github.io/rust-project-perspectives-on-ai/feb27-summary.html


今日互动探讨:

在你的日常开发或开源贡献中,有没有被同事或陌生人提交的“AI 垃圾代码”狠狠坑过?你觉得开源社区应该全面封杀 AI 代码,还是张开双臂拥抱它?

欢迎在评论区疯狂吐槽与分享!


还在为“复制粘贴喂AI”而烦恼?我的新专栏 AI原生开发工作流实战 将带你:

  • 告别低效,重塑开发范式
  • 驾驭AI Agent(Claude Code),实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码,开启你的AI原生开发之旅。


你的Go技能,是否也卡在了“熟练”到“精通”的瓶颈期?

  • 想写出更地道、更健壮的Go代码,却总在细节上踩坑?
  • 渴望提升软件设计能力,驾驭复杂Go项目却缺乏章法?
  • 想打造生产级的Go服务,却在工程化实践中屡屡受挫?

继《Go语言第一课》后,我的《Go语言进阶课》终于在极客时间与大家见面了!

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造!30+讲硬核内容,带你夯实语法认知,提升设计思维,锻造工程实践能力,更有实战项目串讲。

目标只有一个:助你完成从“Go熟练工”到“Go专家”的蜕变! 现在就加入,让你的Go技能再上一个新台阶!


原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球,快来加入星球,开启你的技术跃迁之旅吧!

我们致力于打造一个高品质的 Go 语言深度学习AI 应用探索 平台。在这里,你将获得:

  • 体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏,夯实你的 Go 内功。
  • 前沿 Go+AI 实战赋能: 紧跟时代步伐,学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等,掌握 AI 时代新技能。
  • 星主 Tony Bai 亲自答疑: 遇到难题?星主第一时间为你深度解析,扫清学习障碍。
  • 高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术,碰撞思想火花。
  • 独家资源与内容首发: 技术文章、课程更新、精选资源,第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚,享受技术精进的快乐!欢迎你的加入!

img{512x368}


商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求,请扫描下方公众号二维码,与我私信联系。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言进阶课 AI原生开发工作流实战 Go语言精进之路1 Go语言精进之路2 Go语言第一课 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com
这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats