本文永久链接 – https://tonybai.com/2026/04/25/rust-popularity-vs-redmonk-ranking-reality-check

大家好，我是Tony Bai。

在过去几年的技术圈，Rust 是当之无愧的“流量之王”。

它连续多年在 Stack Overflow 开发者调研中蝉联“最受喜爱的语言”；它是 Linux 内核 30 年来引入的唯一非 C 语言；它是微软、亚马逊等大厂重塑底层安全架构的希望。

如果只看社交媒体和社区讨论，你会觉得 Rust 已经“统治了世界”。在一片赞歌中，大家默认 Rust 杀进主流榜单前十、取代传统语言只是时间问题。

但就在 2026 年 4 月，一份来自权威分析机构 RedMonk 的2026.1编程语言排行榜，却给所有“Rust 狂热者”泼了一盆透心凉的冷水。

数据呈现了一个极其残酷的反差：

在这份以“开发者真实选择”为核心指标的榜单上，Rust 的排名并没有像预期的那样一飞冲天，而是停滞在了第 20 位，甚至被曾被视为小众的 Dart 所超越。相比之下，那个常被调侃“无趣”的 Go 语言，依然稳稳地坐在第 12 位，并在云原生领域保持着统治地位。

为什么人人爱 Rust，但它在工业界的大规模普及却显得如此缓慢？为什么它“攻陷”了最硬核的 Linux 内核，却迟迟进不了普通开发者的日常？

今天，我想结合近期社区的深度讨论，扒开 Rust 这层华丽的外衣，带大家看看这门“天选之子”背后的生存现状与真实挑战。

口碑与数据的鸿沟：被锁死在“塔尖”的生产力

在开发者 Alejandra 最近整理的一份清单里，Rust 的“战绩”堪称辉煌：Windows 11 的核心组件、AWS 的 Firecracker 虚拟化、Cloudflare 的下一代代理服务器 Pingora……

但这恰恰揭示了 Rust 目前最大的尴尬：它是一个“属于 1% 的神兵利器”。

这些成功的 Rust 项目，无一例外都属于“系统级基础设施”领域。它们雇佣的是全球前 1% 的顶级程序员，拥有极其漫长的研发周期和近乎奢侈的调试成本。

正如 RedMonk 的分析师在报告中一针见血地指出：

“Rust 依然面临着非专家程序员难以逾越的学习门槛。专家们愿意投入时间，但更广泛的主流采用似乎面临着巨大的惯性。”

开发者 Alejandra 在其博文的自白中也坦言：

“无论我们如何自我安慰 Rust 已经进入主流，事实是：它离 C++ 甚至 Java 的普及程度，依然有着深不见底的鸿沟。大学教的第一门语言依然是 Java，飞机上依然在用 C++，网页里依然全是 Javascript。”

Rust 已经完成了从 0 到 1 的“极客突围”，却正在撞向从 1 到 N 的“工业化之墙”。

标准库的困局：当“技术洁癖”变成“协作负担”

除了学习曲线，Rust 进军主流的第二个障碍，也许就是它那小而美的标准库。

这篇名为《Unpopular opinion: Rust should have a larger standard library》（非主流观点：Rust 应该有一个更大的标准库）的帖子，戳中了无数一线开发者的泪点：

在我之前写过的一篇文章《别搞“小而美”了！Rust 开发者请愿：求求标准库学学 Go 吧》中也曾提过社区对 Rust 标准库的述求：

“我不想写个程序就要拉几百个三方库！生成一个随机数，std 里没有；想要个异步运行时，std 里也没有。我不得不把信任托付给几百个散落在 GitHub 各地、由个人维护的小型包（Crate）。”

这种对“核心精简”的极致追求，正在引发严重的“供应链安全焦虑”。

在 Go 的世界里，你可以用标准库完成 90% 的后端开发，这意味着你的核心链路是由 Google 顶尖团队直接背书的。但在 Rust 的世界里，开发者面临着“碎片化依赖”的内耗。

这种“标准库贫血”导致了一个反直觉的现象：Rust 是一门为了“安全”而生的语言，但它极度依赖社区包的机制，却在客观上增加了供应链被“投毒”的风险。

正如评论区所感慨的：“标准库是模块最终的坟场。”Rust 团队为了避免标准库变得臃肿，却无意中将“复杂性”和“审计成本”全部转嫁给了一线开发者。这种“技术洁癖”在处理顶级项目时是美德，但在处理追求效率的通用业务时，却成了巨大的阻碍。

Go vs Rust：工业生产力的两种极致审美

为什么 Go 能在 RedMonk 榜单上稳坐第 12，而 Rust 只能在第 20 徘徊？

这是两种完全不同的工程学审美，也决定了它们在大规模协作中的不同命运：

• Go 的审美是“工厂流水线”：它不鼓励个人英雄主义，它用 gofmt 强制所有人的代码长得一模一样。它追求的是“平均生产力的最大化”。即便是一个普通水准的程序员，在 Go 的框架下也很难写出摧毁系统的灾难性代码。这种“无聊”和“简单”，正是大厂进行大规模兵团作战时的首选。
• Rust 的审美是“顶级艺术工作室”：它追求极致的精准、极致的控制。每一个 borrow，每一个 lifetime 都是在进行微雕。它追求的是“个体生产力的上限”。

但在现代软件工业中，“下限的稳定性”往往比“上限的惊艳度”更具普适价值。 绝大多数公司需要的不是一个能手搓编译器的天才，而是一群能够按照既定流程、稳健产出、且易于维护代码的合格工程师。

AI 时代的变数：谁才是对机器最友好的母语？

RedMonk 的报告里还提出了一个极具前瞻性的观察：理论上，AI 编码辅助工具应该能抹平 Rust 的学习曲线，但现实并非如此。

为什么？

大模型（LLM）的本质是模式识别和概率预测。

对于语法单一、推崇“唯一路径”的 Go 语言来说，AI 生成的代码准确率极高，且人类审查的认知负荷极低。

而对于规则极其复杂、生命周期标记繁琐的 Rust 来说，AI 生成的代码极易出现“微妙的语法错误”或“不地道的生命周期设计”。人类开发者在审查 AI 生成的 Rust 代码时，往往比自己重写一遍还要痛苦。

在“机器写代码”即将接管开发流程的未来，简单、标准、甚至有些“死板”的语言，反而拥有更宽、更深的护城河。《HashiCorp 创始人亲口“认错”：AI 让我重新爱上了 Go (文末福利)》一文中Hashicorp创始人Mitchell Hashimoto 因 AI 重新爱上Go，以及Pandas 之父近期更喜欢让 AI 用Go写代码也印证了这一点。

小结：架构师的清醒与权衡

作为一个架构师，我们不必因为 Rust 在榜单上的“冷水”而否定它的伟大。

Rust 正在解决软件工程中最难的问题——在不牺牲性能的前提下，从根源上消灭内存漏洞。它的价值，已经在 Linux 内核和那些“不容有失”的领域得到了证明。

但我们也必须清醒地认识到：技术的流行度（Popularity）与技术的高级感（Elegance）并不总是正相关。

如果你在构建下一代安全操作系统、数据库内核或高性能边缘网关，Rust 是你不二的利剑。

但如果你在构建一个需要快速迭代、支撑公司核心营收、且由几十甚至上百人协作的后端业务系统，请务必保持客观：那个排名第 12、虽然有些“平庸”但永远能准时交付、且对 AI 极度友好的 Go，或许才是那个更优的工程方案。

再次祭出那句话：你的技术护城河，从来不是由你用什么语言决定的，而是由你解决问题的深度，以及你在各种极端权衡（Trade-offs）中做出的选择决定的。

资料链接：

• https://blog.goose.love/posts/what-actually-uses-rust/
• https://www.reddit.com/r/rust/comments/1sqyjxa/blog_ok_what_actually_uses_rust/
• https://redmonk.com/sogrady/2026/04/14/language-rankings-1-26/

今日互动探讨：

看完这份“人人爱 Rust，但榜单很冷酷”的现实反差，你觉得 Rust 挺进主流最大的障碍是什么？你认为“大标准库”是未来编程语言的必然趋势吗？

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

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

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

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

原「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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

本文永久链接 – https://tonybai.com/2026/04/09/stop-being-small-and-beautiful-rust-petition-to-learn-from-go

大家好，我是Tony Bai。

如果你之前经常听 Go 社区最火的播客 GoTime(很遗憾，该播客2024年末因平台原因停播了)，你一定会熟悉每期节目最后的那个经典环节——“Unpopular Opinion”（非主流观点）。在这个环节，嘉宾们会分享一些看似离经叛道、却往往一针见血的“暴论”。

但就在前几天，这个流行于 Go 社区的“梗”，却被隔壁的 Rust 社区“偷”了过去，并掀起了一场史诗级的“路线之争”。

一位 Rust 开发者，在 r/rust 论坛上发了一篇帖子，标题就叫：《Unpopular opinion: Rust should have a larger standard library》（非主流观点：Rust 应该有一个更大的标准库）。

他在这篇帖子中发出了灵魂拷问：

“我不想为了写一个程序，被迫去拉几百个我根本没时间、也没人去审计的第三方依赖包。看看隔壁的 Go 是怎么做标准库的，你几乎可以不依赖任何三方包就构建出复杂的系统！”

这篇帖子瞬间引爆了 Rust 社区。短短一天，帖子收获了近 700 的高赞和近 300 条激烈辩论。

这看起来像是一场简单的“库多库少”之争，但本质上，它背后是 Rust 这门以“零成本抽象、极致安全”著称的语言，在面对日益猖獗的供应链安全威胁和 Go 语言“开箱即用”的降维打击时，所爆发的一场深刻的身份危机与哲学反思。

“小而美”的代价：悬在每个 Rust 项目头顶的达摩克利斯之剑

长期以来，Rust 社区一直为自己“小核心、强生态”的模式感到自豪。Rust 的标准库（std）极其精简，只提供最基础、最核心的功能。任何稍微高级一点的需求，比如随机数生成、异步运行时、序列化，官方都鼓励你去 crates.io 上找社区“钦定”的“明星库”（Blessed Crates）。

这套模式在早期极大地促进了生态的繁荣。但随着 npm left-pad 事件和各种开源投毒攻击的阴影笼罩全球，这套模式的代价也变得越来越难以承受。

原帖作者一针见血地指出了所有人的噩梦：

“是的，你可以采取各种缓解措施。但等你发现某个藏在你依赖树第三层的、不起眼的包被植入了恶意软件时，你的服务器密钥可能早就被偷光了！”

评论区里的一位开发者用一句话概括了所有人的痛点：

“我完全同意。有时候 std 里就是缺了那么一点至关重要的东西。我能理解这背后的原因，但为了生成一个随机数就要去装一个第三方包，这实在有点小题大做了。”

这正是 Rust 开发者面临的尴尬：当你只是想生成一个 UUID，或者发起一个 HTTP 请求时，你被迫要对 rand、reqwest、tokio 这些由社区个人或小团体维护的库，付出与 Rust 官方核心团队同等级别的“信任”。

而这种信任，正在变得越来越昂贵和危险。

隔壁的诱惑：Go 语言的“大一统”模式

在这场大讨论中，一个名字被反复提及，它就是 Go 语言。

Go 从诞生之初，就选择了与 Rust 截然相反的“自带电池（Batteries Included）”哲学。

• 你想做 Web 开发？net/http 原生支持，性能强大到可以直接裸奔在生产环境。
• 你想做 JSON/XML 解析？encoding/json(以及实验性的encoding/json/v2)、encoding/xml 是标配。
• 你想做并发？goroutine 和 channel 是语言级原生特性。
• 你想生成随机数？math/rand、crypto/rand 随便用。

评论区里，一位 Rust 开发者的对比极其扎心：

“把恶意代码偷偷塞进一个（流行的）Crate 的第四层依赖里，比把它塞进 Rust 的 std 里要容易得多。”

Go 语言通过一个庞大、稳定、由官方核心团队直接维护的标准库，为开发者提供了一道坚固的“安全护城河”。你可以在不引入任何一个第三方依赖的情况下，构建出一个功能极其完备、性能强大的高并发网络服务。

这种“开箱即用”的安全感和便利性，对于那些深受供应链安全审计折磨的企业开发者来说，是致命的诱惑。

社区的挣扎：当“保守”成为“瓶颈”

面对社区的“呐喊”，Rust 核心团队的成员和社区大佬们也纷纷下场，给出了极其理性和深刻的解释。他们的回复，揭示了 Rust 在标准库扩张上，面临的“三重枷锁”。

枷锁一：向后兼容性的“诅咒”

一位核心成员引用了 Python 社区的一句名言：

“标准库，是模块最终的坟场（The standard library is where modules go to die）。”

一旦一个 API 进入了 std，它就必须背上永不破坏向后兼容的沉重承诺。哪怕 10 年后发现这个设计有缺陷，也只能眼睁睁地看着它腐烂，或者推出一个 urllib2、urllib3 这样极其丑陋的补丁。

Rust 团队宁愿让这些库在社区里自由进化、大浪淘沙，等到它们的设计真正成熟、稳定到可以“永恒”时，再考虑纳入 std。比如 once_cell 和最新的 rand（目前在 nightly 版本中）。

枷锁二：无休止的“维护地狱”

另外一名核心成员指出，将一个库纳入 std，意味着它的维护成本将全部转移到人数本就捉襟见肘的官方维护者身上。而在社区，每个 Crate 都有自己专门的维护者。这是两种完全不同的成本模型。

枷锁三：设计的“过早僵化”

最典型的例子就是异步。原帖作者提议：“Rust 能不能偷一下 Zig 的 IO 思想，这样我们就不需要在 Tokio 和 non-Tokio 生态之间分裂了？”

一位社区大佬立刻反驳：Zig 没有 Rust 的 Send/Sync 标记，两者的异步模型有本质区别。Rust 的异步生态之所以看起来“分裂”，恰恰是语言给了开发者在不同场景下做最优选择的自由。如果过早地在 std 里统一一个官方运行时，反而会扼杀创新。

破局之路：从“大一统”到“邦联制”

在这场激烈的辩论中，一些极具建设性的“折中方案”也开始浮现。这或许预示着 Rust 未来的演进方向。

方案一：官方背书的“准标准库（Semi-official）”

一位开发者提出，Rust 项目组可以借鉴 C++ Boost 库的模式，官方接管 serde、rand、tokio 这些“钦定”的明星库，将它们纳入一个统一的 extd (extended) 命名空间下。

use extd::regex::Regex;
use extd::rand;

这并不会增加 std 的体积，但给了这些库一个“官方认证”的金字招牌，极大地解决了开发者的信任和审计问题。

方案二：引入“孵化期（Incubation Phase）”

一位开发者建议，应该有一个更明确的孵化流程，让那些有潜力进入 std 的库，先在一个类似 Go golang.org/x 的“实验场”里进行检验，而不是直接从某个个人开发者仓库里一步登天。

方案三：强化 Cargo 的安全审计能力

一些核心成员则认为，问题的根源不在于 std 的大小，而在于 crates.io 的分发机制不够安全。与其“因噎废食”地把所有东西都塞进 std，不如去建立更强大的包安全审计机制，比如：

• 发布隔离期：新发布的包必须经过 72 小时自动化扫描才能被下载。
• 签名与信任链：通过 cargo 增强包签名和审计者签名，让企业可以选择只使用“可信审计者”批准的依赖列表。

小结：一场关于“灵魂”的拷问

这场由“非主流观点(Unpopular Opinion)”引发的大讨论，表面上是在争论标准库的大小，但其核心，却是一场关于 Rust 与 Go 两种截然不同建国哲学的灵魂拷问。

• Go 语言，像一个大一统的、中央集权的帝国。它为你提供了从道路、货币到度量衡的一切基础设施。你享受着极高的安全感和便利性，代价是必须忍受它某些时候的“独裁”与“不灵活”。
• Rust 语言，则更像一个松散的、充满活力的城邦联盟。官方只提供最基础的法律和军队，剩下的一切都交给各个城邦（Crates）自由发展。你拥有无与伦比的自由和选择权，代价是你必须自己承担选择的风险，并时刻提防“外敌入侵”（供应链攻击）。

这两种哲学没有绝对的优劣，只有不同场景下的取舍。

但 Rust 社区的这场“请愿”，无疑为我们所有技术人敲响了警钟：在软件供应链日益脆弱的今天，一个强大、可靠、由顶级专家背书的“官方基础设施”，其价值正在被无限放大。

或许，Rust 的未来，真的需要在“自由”与“安全”之间，找到一个新的平衡点。而隔壁 Go 的作业，他们可能真的需要抄一抄了。

资料链接：https://www.reddit.com/r/rust/comments/1seu7p2/unpopular_opinion_rust_should_have_a_larger/

今日互动探讨：

在你的日常开发中，你是更喜欢 Go 这种“自带电池”的大标准库模式，还是 Rust 这种“小核心+强生态”的自由模式？你是否也曾因为“拉了一堆三方库”而感到安全焦虑？

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

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

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

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

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

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

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

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

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

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