本文永久链接 – https://tonybai.com/2025/06/20/redmonk-index-2025-jan

大家好，我是Tony Bai。

编程语言的江湖，总是风起云涌，新旧更迭。而 RedMonk 编程语言排行榜，以其独特的视角（结合 GitHub 的代码活跃度和 Stack Overflow 的讨论热度），长期以来都是我们观察这片江湖风向的重要参考。

就在最近，RedMonk发布了其2025年1月的编程语言排行榜。榜单本身波澜不惊，Top 20 的名单几乎与上一期如出一辙，这似乎预示着编程语言领域正进入一个相对“固化”的时期。然而，在这份看似平静的榜单背后，却潜藏着一个巨大的变量，一个足以让 RedMonk 自身都开始反思其排行方法论的“房间里的大象”——那就是 AI 的崛起，及其对 Stack Overflow 数据源的颠覆性冲击。

今天，我们就来解读这份最新的 RedMonk 排行榜，看看 Go 语言在其中表现如何，更重要的是，探讨在 AI 时代，我们该如何看待这类排行榜，以及 Go 语言的未来又将走向何方。

RedMonk 排行榜：方法论回顾与本次看点

在解读具体排名之前，我们有必要简单回顾一下 RedMonk 排行榜的方法论。它并非统计当前“谁用得多”，而是试图通过两个维度的数据来预测语言的未来采用趋势：

1. GitHub 数据： 主要通过 GitHub Archive 拉取数据，分析代码提交中使用的语言，代表了语言在实际项目开发中的活跃度和受开发者青睐的程度。
2. Stack Overflow 数据： 通过其 Data Explorer 查询，分析特定语言标签下的问题和讨论数量，代表了语言在开发者社区中的关注度和开发者在学习、使用过程中遇到的问题量（间接反映了活跃度）。

RedMonk 强调，榜单的“分层 (Tiering)”比具体的数字名次更重要，因为精确排名本身就存在误差。同时，对于排名靠后的语言，由于数据量较小，其排名的波动性和不确定性会更大。

本次 2025 年 1 月的排行，最大的看点莫过于 RedMonk 博客作者 Stephen O’Grady 对 Stack Overflow (以下有时简称SO)数据有效性的公开疑虑。他明确指出，随着 ChatGPT、GitHub Copilot 等 AI 工具的普及，开发者遇到问题时，直接向 AI 提问的比例越来越高，而去 Stack Overflow 搜索或提问的需求显著下降。这导致 Stack Overflow 整体流量和特定语言标签下的讨论量都在萎缩，从而可能扭曲了基于 StackOverflow 数据的排名。RedMonk 甚至在考虑未来是否要调整 SO 数据的权重，甚至完全放弃使用它。

这无疑为我们解读本次榜单，尤其是观察那些 SO 数据占比较重的语言，提供了一个全新的、也是更具挑战性的视角。

Go语言：稳坐 Top 12，GitHub 根基深厚

在这样的背景下，我们来看看Go语言的表现：

• 排名： Go 语言在此次排行中位列 第 12 位，与统计语言 R 并列。
• 稳定性： Top 20 的榜单几乎“纹丝不动”，Go 的排名也保持了稳定。回顾历史，Go 从 2015 年的第 17 位，稳步上升，并在近几年持续超越了曾经在 JVM 生态中势头强劲的 Scala 和 Kotlin。
• 解读 Go 的“稳”： 在 Stack Overflow 数据可能“失真”、整体排行趋于“凝固”的大环境下，Go 语言能够牢牢占据 Top 12 的位置，这本身就充分说明了其在 GitHub 上的代码活跃度和开发者基础的极端稳固。这与 Go 在云原生、后端服务、基础设施等领域的深厚积累和广泛应用密不可分。

关键语言动态：Go 在比较中更显价值

RedMonk 的博文还特别点出了一些值得关注的语言动态，通过与这些语言的对比，我们可以更清晰地看到 Go 的独特价值和发展趋势。

• TypeScript (第 6) 的“平台期”与 Go 的“幕后英雄”角色

尽管 TypeScript 在 JavaScript 生态中不可或缺，其排名也高居第 6，但博文指出它似乎进入了一个“增长平台期”，难以再向上突破。

RedMonk 提到了 TypeScript 在可扩展性 (scalability) 方面可能遇到的挑战，并直接点名了微软决定使用 Go 语言重写 TypeScript 的编译器 (tsc) 和相关工具链这一标志性事件。

当然，这无疑是对 Go 语言在构建大规模、高性能开发工具和基础设施方面能力的最好背书。当连 TypeScript 这样的语言工具自身都遇到扩展性瓶颈时，他们选择了 Go 作为解决方案。这充分证明了 Go 在工程效率、编译速度、并发处理和静态二进制部署等方面的核心优势，使其成为构建下一代开发工具（编译器、Linter、语言服务器等）的优选语言。Go，正在成为越来越多关键技术的“幕后英雄”。

• Kotlin (并列 14) / Scala (并列 14) 的“增长天花板”

这两位 JVM 生态的“优等生”排名稳定，但向上突破的动力似乎不足。Go 早已在排名上超越它们。

随着 Go 在微软等传统“非 Go”大厂中找到新的应用场景（如上述 TypeScript 工具链），以及 Rust 在对安全和性能有极致要求的服务端负载中逐渐蚕食地盘，Kotlin 和 Scala 的增长路径面临着不小的挑战。

Go 凭借其简洁的语法、高效的并发模型、出色的网络性能、以及与云原生生态的无缝集成，在现代后端服务开发领域，对传统的 JVM 语言形成了持续且强劲的竞争压力。对于追求快速迭代、高并发、低资源占用的新项目，Go 往往是更具吸引力的选择。

• 新兴语言 (Ballerina, Bicep, Zig 等) 的“SO 困境”

许多被 RedMonk 关注的新兴语言，在本次排名中大多出现了下滑，并且呈现出 GitHub 排名远好于 Stack Overflow 排名的特点。

这很可能就是前文提到的 AI 对 Stack Overflow 数据冲击的直接体现。新兴语言本身在 SO 上的讨论基数就小，当整体 SO 流量下降时，它们受到的负面影响会更加不成比例。

这再次提醒我们，在评估语言趋势时，需要警惕单一数据源（尤其是易受外部因素干扰的数据源）的局限性。Go 之所以能在榜单中保持稳定，更多是依赖其在 GitHub 上庞大且活跃的真实代码贡献和项目应用，这比社区讨论热度更能反映语言的实际生命力。

AI 时代，编程语言排行榜的挑战与 Go 的新机遇

AI 代码助手（如 ChatGPT, GitHub Copilot）的普及，正在深刻改变开发者的工作习惯。遇到问题，许多人可能首先想到的是“问 AI”，而不是去 Stack Overflow 搜索或提问。这对依赖 SO 数据的 RedMonk 排行榜方法论构成了前所未有的挑战。Stephen O’Grady 的坦诚，也预示着未来编程语言趋势的观察方法可能需要革新。

在这样的背景下，Go 语言的机遇何在？

1. GitHub 数据权重可能提升： 如果 SO 数据权重下降或被弃用，那么更能反映语言实际使用和生态发展的 GitHub 数据将变得更加重要。Go 在这方面一直表现强劲，拥有大量高质量的开源项目和活跃的贡献者。
2. AI 基础设施的构建者： 正如我在之前的文章中多次提到的，Go 语言凭借其高性能、高并发、易部署的特性，非常适合构建支撑 AI 大模型训练、推理服务的底层基础设施（如分布式计算框架、模型服务平台、向量数据库、数据管道等）。许多流行的 AI 开源项目（如 Ollama）也选择使用 Go。
3. AI 应用的工程化落地： AI 模型最终需要被集成到实际的应用和服务中才能产生价值。Go 的简洁性、强大的网络库、以及出色的工程化特性（如编译速度、静态部署），使其成为将 AI 模型快速、可靠地工程化、产品化的优秀选择。
4. “工具的工具”： Go 在构建开发工具方面的优势，在 AI 时代将更加凸显。无论是构建 AI 代码分析工具、模型部署工具，还是 AI 辅助开发平台的后端，Go 都能胜任。
5. 对 LLM 的“友好性”探索： 虽然目前 Go 在 LLM 训练数据中的占比可能不如 Python，但 Go 语言相对简单的语法、明确的类型系统、以及强大的标准库，是否可能在未来使其更容易被 LLM 理解、分析和生成高质量代码？这是一个值得探索的方向。

小结：喧嚣之中，坚守价值，拥抱未来

RedMonk 的最新编程语言排行榜，在 AI 席卷技术圈的当下，给我们带来了新的思考。Stack Overflow 讨论热度的“失真”，或许只是 AI 改变我们工作和学习方式的一个缩影。

对于 Go 语言而言，其在榜单中的稳定表现，特别是在 GitHub 维度上的持续强势，证明了其深厚的开发者基础和旺盛的生态活力。像微软选择用 Go 重写 TypeScript 工具链这样的行业案例，更是对其核心竞争力的有力印证。

面对 AI 带来的不确定性，Go 语言凭借其在构建高性能网络服务、云原生基础设施、以及高效开发工具等领域的明确价值定位，依然展现出强大的韧性和广阔的前景。未来，它不仅将继续作为这些领域的中流砥柱，更有望在 AI 基础设施和工程化领域扮演越来越重要的角色。

作为 Gopher，我们既要看到排行榜数据的变化，更要理解变化背后的深层逻辑。坚守 Go 语言的核心价值，持续学习和实践，同时对新技术保持开放和探索的心态，这或许才是我们在这个快速变化的时代中，最稳妥的前行之道。

你对这份 RedMonk 榜单有什么看法？AI 的出现改变了你获取技术信息的习惯吗？欢迎在评论区分享你的观点！

精进有道，更上层楼

极客时间《Go语言进阶课》上架刚好一个月，受到了各位读者的热烈欢迎和反馈。在这里感谢大家的支持。目前我们已经完成了课程模块一『语法强化篇』的 13 讲，为你系统突破 Go 语言的语法认知瓶颈，打下坚实基础。

现在，我们已经进入模块二『设计先行篇』，这不仅包括 API 设计，更涵盖了项目布局、包设计、并发设计、接口设计、错误处理设计等构建高质量 Go 代码的关键要素。

这门进阶课程，是我多年 Go 实战经验和深度思考的结晶，旨在帮助你突破瓶颈，从“会用 Go”迈向“精通 Go”，真正驾驭 Go 语言，编写出更优雅、
更高效、更可靠的生产级代码！

扫描下方二维码，立即开启你的 Go 语言进阶之旅！

感谢阅读！

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

本文永久链接 – https://tonybai.com/2025/06/16/go-avoid-critical-incident

大家好，我是Tony Bai。

科技圈的每一次“风吹草动”，尤其是大型云服务的故障，总能引发我们技术人无数的讨论与反思。最近，一则关于“Google Cloud Platform (GCP) Service Control 在 2025 年 6 月发生重大故障”的消息，及其事后分析报告中直指的“null pointer crash loop”，在技术社区掀起了不小的波澜。

故障报告中还提到了几个雪上加霜的因素：没有特性标志 (Feature Flags) 进行高风险部署、缺乏优雅的错误处理（二进制文件直接崩溃而非优雅降级）、以及没有回退机制导致系统过载。

考虑到 Go 语言在 Google 内部（如 Kubernetes, Cloud Run 等）以及整个云原生领域的广泛应用，一个自然而然的疑问浮出水面：Go语言是否是这次 GCP 故障的“元凶”？或者说，Go 的某些特性，是否在某种程度上“助长”了这类问题的发生？反过来，Go 的设计又是否本可以帮助避免这样的灾难？

这这篇文章中，我们就结合社区的智慧，从Go语言特性和更广泛的软件工程实践角度，来剖析一下这类故障背后的深层原因。这不仅是对一个故障的假想复盘，更是对我们日常开发实践的一次警醒。

Go 语言特性：是“防火墙”还是“导火索”？

社区论坛上的讨论，首先就聚焦在了 Go 语言本身的一些特性上。

显式错误返回 (if err != nil)：万无一失还是“防君子不防小人”？

有开发者认为，Go 标志性的显式错误返回设计（即函数返回 (value, error)，调用者必须检查 err），本应是避免错误的有力武器。但也有观点指出，这种模式的“简洁性”（或者说，可以通过 _ 忽略错误的便利性）有时反而可能在项目压力大、追求快速上线时，被开发者有意或无意地跳过，导致潜在的错误处理缺失。比如常见的 value, _ := someFunction() 写法。

Go的显式错误返回，确实为构建健壮软件提供了坚实的基础。它将错误视为一等公民，迫使开发者直面错误处理。但语言提供的机制，终究不能替代开发者的责任心和良好的编码习惯。正如有些开发者提到的，golangci-lint 这样的静态检查工具可以有效地发现未检查的错误，但这需要团队将其融入开发流程并严格执行。**语言设计提供了“防火墙”，但工程师的素养和流程的完备性，才是决定防火墙是否真正起作用的关键。

Nil Pointer Panic：Go 也难逃的“魔爪”？

针对报告中提到的“null pointer crash loop”，许多评论者指出，nil 指针 panic 在 Go 中也并非罕见。Go 语言本身允许指针存在，也允许指针为 nil，并且不像 Rust 的 Option/Result 类型或 C# 的可空引用类型那样，在语言层面强制开发者处理潜在的 nil 情况。

的确，Go 语言的设计哲学是简洁，它相信开发者有能力正确处理指针。避免 nil panic 的核心在于良好的编码实践：防御性编程（在使用指针前进行检查）、最小化指针使用（Go 鼓励值传递，许多场景可以完全避免指针）、以及充分的测试（特别是边界条件和异常路径）。虽然 Go 没有语言层面的强制 nil 检查，但其简洁性也使得这类检查的成本相对较低。

panic/recover 机制：救命稻草还是饮鸩止渴？

有开发者分享经验，倾向于用 panic/recover 包裹所有核心逻辑，试图捕获所有潜在的运行时崩溃。但针对像故障中提到的 Service Control 这样的有状态、高关键性的系统，这种做法也引发了质疑：recover 后的程序状态是否真的可靠？强行“续命”一个可能已处于不一致状态的进程，是否比让它快速失败并由外部监控系统（如 Kubernetes）重启更安全？关于这个问题，我曾在《“这代码迟早出事！”——复盘线上问题：六个让你头痛的Go编码坏味道》一文中也讨论过。

panic/recover 在 Go 中有其特定的适用场景，例如在库的边界将内部的 panic 转换为 error 返回给调用者，或者处理真正意外且难以通过常规错误处理覆盖的严重问题。但对于关键业务服务，尤其是有状态的服务，“fail fast” 依然是目前社区认为的更可取的设计。让服务在遇到严重内部错误时快速、干净地退出，依赖外部的健康检查和自动重启机制来恢复服务，往往比试图在不确定的状态下继续运行更稳妥。

这样来看，Go 语言的设计，如显式错误处理，确实为构建可靠系统提供了工具。但它并不提供“银弹”，也不能完全消除诸如 nil 指针解引用这类逻辑错误的可能性。语言特性是基础，但绝非全部。

超越语言：流程、测试与工程文化的“灵魂拷问”

在针对该故障的讨论中，一个压倒性的共识是：这类大型系统故障，往往更多是软件工程流程、测试策略和工程文化上的问题，而非单一语言设计所能左右。

“100% 测试覆盖率”的迷思与测试策略的缺位

有开发者提出“你可以覆盖 100% 的代码行，但你永远无法覆盖 100% 的输入和状态组合。” 这句话一针见血。过度迷信行覆盖率，而忽略了测试的深度和广度，是许多团队的通病。

那么真正有效的测试策略应该是什么呢？显然单一的测试策略是无法保证程序上线后的质量的。下面是几种常见的测试策略：

• 单元测试 (Unit Testing): 验证开发者对代码单元在预期输入下的行为。
• 模糊测试 (Fuzz Testing): 通过自动生成大量随机或变异输入，探索代码的边缘情况和未知缺陷。Go 1.18 已将 Fuzz Testing 内置到标准工具链中，这是一个强大的武器。
• 集成测试 (Integration Testing): 验证模块间的交互。
• 端到端测试 (End-to-End Testing): 模拟真实用户场景。
• 生产测试/灰度发布 (Staged Rollouts / Canary Releases): 在真实生产环境中，小范围、逐步地验证变更的可靠性，这是大型系统发布的“金丝雀”。

这些策略显而易见，但又有多少团队能真正全面的做到呢？

特性标志 (Feature Flags)：高风险变更的“安全阀”

故障报告中提到了“没有特性标志进行风险部署”，这几乎是大型系统发布的“大忌”。特性标志允许团队在不重新部署代码的情况下，动态地开启或关闭某项功能，从而：

• 安全地进行 A/B 测试。
• 逐步向用户灰度上线新功能，控制风险。
• 在出现问题时，能够快速关闭故障功能，实现秒级“回滚”（功能层面）。

缺乏特性标志，意味着任何高风险的变更都像是在“裸奔”。

优雅降级与回滚预案：Plan B 的重要性

系统出错在所难免，关键在于出错后如何表现。故障报告中“二进制崩溃而非优雅降级”以及“没有随机回退导致过载”，都指向了系统鲁棒性的缺失。

• 优雅降级: 当核心服务出现问题时，非关键功能是否可以降级服务，保证核心可用性？例如，推荐系统不可用时，是否可以展示默认热门内容，而不是整个页面崩溃？
• 回滚计划: 任何部署都应该有明确、经过演练的回滚计划。出现问题时，能否快速、安全地回退到上一个稳定版本？

代码审查、自动化工具与工程文化

• 严格的代码审查: 是发现逻辑错误、不规范写法（如忽略错误、滥用指针）的重要手段。
• 静态分析与 Linter：golangci-lint 等工具可以自动化地检查出大量潜在问题，包括未处理的错误、不安全的并发操作等。但正如有些开发者在评论中所言，“linters can be disabled”，关键还是在于流程的执行。
• 警惕“Vibe Coding”：有开发者犀利地指出“Garbage in, garbage out”。如果团队强依赖AI的“氛围”编码，而缺乏对生成代码的审查，那么无论用什么语言，都可能埋下隐患。
• 重视流程而非迷信工具：许多评论都强调，即使有再好的语言特性或工具，如果缺乏健全的开发、测试、部署流程，以及对质量负责的工程文化，故障依然难以避免。

AI 辅助编程：是“帮手”还是新的“风险源”？

一个有趣的衍生讨论是关于 AI 辅助编程（如 GitHub Copilot、Google Gemini Code Assist）在其中的角色。

有开发者提到，Google 内部已有大量代码由 Gemini 生成。也有人分享使用 AI 辅助编程的体验，认为其在作为“结对编程伙伴”或“辅助搜索”时有价值，但完全自动生成的代码质量参差不齐，有时甚至会引入“幻觉”和新的 bug。

AI 辅助编程无疑是未来的趋势，它有可能提高开发效率，辅助开发者处理重复性工作。但目前来看，AI 生成的代码更需要、而不是更不需要人类的严格审查和充分测试。将 AI 视为一个能提供建议、加速编码的助手是合适的，但如果过度依赖，甚至将其生成的代码不经审视直接合入生产，那无异于引入了新的、更不可控的风险源。特别是在错误处理、并发安全、边界条件这些需要深度思考的领域，AI至少目前还难以完全替代经验丰富的工程师，尤其是一些mission critical的系统中。不要被那些用AI生成一个简单工具站的“AI战果”所迷惑。

小节：语言是利器，工程实践才是灵魂

回到最初的问题：GCP Service Control 的这次故障，Go 语言是“元凶”还是“背锅侠”？

从 社区的讨论和我们的分析来看，将板子完全打在 Go 语言身上，显然是有失公允的。Go 语言的设计，如其显式错误处理、简洁性带来的高可读性、以及强大的并发能力，都为构建健壮、高效的系统提供了良好的基础。

然而，语言终究只是工具，它不能替代健全的软件工程流程和严谨的工程文化。 此次 GCP 故障所暴露出的问题——无论是可能的 nil 指针解引用，还是更宏观的缺乏特性标志、部署策略失当、错误处理不优雅——更多地指向了在测试、部署、风险控制、质量保障等一系列工程实践环节可能存在的缺失。

对于我们 Go 开发者而言，这次事件给我们带来的启示应该是：

• 充分利用 Go 的优势： 写出符合 Go 惯例的、清晰的错误处理逻辑；审慎使用指针，做好 nil 检查；发挥 Go 并发模型的威力。
• 拥抱并严格执行工程最佳实践： 将单元测试、集成测试、模糊测试落到实处；在重要变更上线时，务必使用特性标志和灰度发布策略；建立严格的代码审查机制；利用好静态分析工具。
• 对 AI 保持理性： 善用 AI 辅助工具提高效率，但绝不能放松对代码质量的把控和人工审查的力度。

最终，构建一个真正高可用、高可靠的大型系统，依赖的绝不仅仅是选择一门“好”的语言，更在于整个团队对卓越工程实践的持续追求和严格执行。

你对这次讨论有什么看法？或者在你的 Go 项目中，是如何保障系统稳定性的？欢迎在评论区留下你的宝贵经验！

精进有道，更上层楼

极客时间《Go语言进阶课》上架刚好一个月，受到了各位读者的热烈欢迎和反馈。在这里感谢大家的支持。目前我们已经完成了课程模块一『语法强化篇』的 13 讲，为你系统突破 Go 语言的语法认知瓶颈，打下坚实基础。

现在，我们即将进入模块二『设计先行篇』，这不仅包括 API 设计，更涵盖了项目布局、包设计、并发设计、接口设计、错误处理设计等构建高质>量 Go 代码的关键要素。

这门进阶课程，是我多年 Go 实战经验和深度思考的结晶，旨在帮助你突破瓶颈，从“会用 Go”迈向“精通 Go”，真正驾驭 Go 语言，编写出更优雅、
更高效、更可靠的生产级代码！

扫描下方二维码，立即开启你的 Go 语言进阶之旅！

感谢阅读！

如果这篇文章让你对Go语言有了新的认识，请帮忙转发，让更多朋友一起学习和进步！

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