Java - Tony Bai

标签 Java 下的文章

AI正在重塑编程语言格局：Rust、Python 和 TypeScript 真是最终赢家吗？

八月 14, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/08/14/rs-py-ts-trifecta

大家好，我是Tony Bai。

在 AI 浪潮席卷而来的今天，一个深刻的问题正摆在所有开发者面前：我们手中的编程语言，将如何被这股力量重塑？我们未来的技能投资，应该押注在哪里？

最近，Rust 核心团队的 Niko Matsakis，在他的一篇博文中给出了一个大胆的预测：Rust、Python 和 TypeScript 将成为未来的主导语言（移动端除外），形成新的“三驾马车”。

他的核心论点极具说服力：AI 正在削弱我们的“语言忠诚度”。过去，我们选择最熟悉的语言以求最快，因为学习新语言和其生态的成本太高。但现在，AI 正在改变这一切。

Niko 写道：“当我使用 AI 助手构建项目时，我的思维方式不同了。我更多地考虑有哪些库可用，我的基本性能需求是什么，以及我期望与哪些平台集成。” 换言之，AI 正在帮助我们克服学习曲线的“坑”，让我们得以回归本源，为任务选择“基础最扎实”的语言。

而这“三驾马车”，恰好占据了最关键的生态位：

Rust： 系统与性能的基石，以其无与伦比的内存安全和效率成为底层开发的首选。
Python： 数据与实验的引擎，凭借其在科学计算和机器学习领域的绝对统治力，主导原型设计和数据应用。
TypeScript： Web 与应用的界面，作为 Web 的“母语”，在浏览器和众多跨平台应用中拥有不可替代的地位。

这个预测听起来逻辑严谨，几乎无懈可击。然而，当我们把目光从理想的“基础”，转向现实世界的复杂工程实践时，一些强大的“挑战者”浮出水面，它们的故事，同样值得倾听。

一种新的编程范式：“想法导向编程”

在深入辩论之前，我们必须先理解 Niko 提出的一个核心概念，它支撑着整个预测的基石——“想法导向编程” (Idea-Oriented Programming, IOP)。

这并非是那种懒散、模糊地对 AI 说“给我做个XX”的“氛围编程 (Vibe Coding)”。IOP 是一种严谨的编程范式，它重新定义了人与 AI 的关系：

“开发者更像是首席架构师，而你的编码工具就像是你的学徒。你思考目标和关键设计，制定清晰的计划，并将重活累活授权给工具——然后你审查它们的产出，并进行调整。”

在这种模式下，AI 不是“神灯精灵”，而是你的“学徒”。它负责处理繁琐的实现细节，而你，则被解放出来，专注于更高层次的、创造性的工作。正是这种角色的转变，使得“语言基础”变得比“个人熟练度”更重要。

然而，这个看似完美的预测，真的无懈可击吗？

挑战者一：Go 语言的“反击”——简洁即力量

Niko 的预测，似乎忽略了一个在工程效率中至关重要的因素——简单性 (Simplicity)。而这，正是 Go 语言的立身之本。

1. 真正的“AI 友好”： Niko 强调，强大的类型系统对 AI 来说是至关重要的“护栏”。这一点毋庸置疑。但 AI 同样面临“认知负荷”的问题。AI 极其擅长生成 Go 这种规则简单、没有“魔法”、风格统一的样板代码。但让 AI 完美处理 Rust 复杂的生命周期和所有权，或者 TypeScript 中层出不穷的类型体操，至今仍是一个巨大的挑战。在未来“人机协作审查”的开发模式下，哪种语言对审查者更友好？答案不言而喻。

2. 工程效率的真谛： AI 能加速“编码”，但无法加速“决策”。Go 强大的标准库和“小而美”的生态，为开发者提供了一条清晰的“默认路径”，极大地避免了在技术选型上陷入“分析瘫痪”。在一个团队中，这种由简洁性带来的决策效率和低认知负荷，是实实在在的生产力。

3. 并发模型的优势： 在云原生和后端服务的核心地带，Go 的 Goroutine + Channel 并发模型，其简单性和在高 I/O 吞吐场景下的卓越表现，依然是难以被撼动的“杀手锏”。

Go 语言似乎在用它的整个设计哲学反问：当 AI 能处理大部分实现细节时，我们人类开发者最宝贵的资源——注意力——应该花在与语言的复杂性搏斗上，还是花在业务逻辑和系统设计上？

挑战者二：Java/JVM 生态的“护城河”——惯性即引力

Niko 的预测，也可能低估了企业级市场的惯性，以及 JVM 生态那深不见底的“护城河”。

1. 庞大的生态与人才库： 全球数百万的 Java 开发者，以及由 Spring 等框架构建起来的、支撑着全球无数核心业务的庞大系统，不会在一夜之间消失。AI 或许能帮你写一个 CRUD，但无法替代一个经验丰富的架构师来驾驭一个复杂的企业级系统。

2. 虚拟机的力量： JVM 本身就是一层极其强大的抽象。它提供了无与伦比的跨平台能力、经过数十年优化的运行时性能、以及一整套成熟到“令人发指”的调试、监控和性能分析工具。对于追求长期稳定和可维护性的大型企业来说，这种确定性本身就是一种最“扎实”的基础。

3. 新语言的活力： 别忘了，JVM 生态并非只有 Java。像 Kotlin、Scala和Clojure 这样的现代化语言，既享受了 JVM 的全部生态红利，又提供了强大的类型系统和函数式编程能力，它们同样是“三驾马车”的有力竞争者。

在追求“基础扎实”的企业世界里，Java/JVM 生态的稳定性和成熟度，本身就是一种难以被轻易取代的引力。

小结：一场关于“什么最重要”的伟大辩论

Niko 的预测，与其说是一个结论，不如说它开启了一场关于“AI 时代，什么才是最重要的语言特性”的伟大辩论。

“三驾马车”的拥护者认为： 是强大的类型系统和繁荣的库生态，它们为 AI 提供了最坚实的基础和最丰富的工具。
Go 的支持者反驳道： 是极致的简洁性和低认知负荷，它们将人类从复杂性中解放出来，专注于创造。
Java/JVM 的捍卫者则强调： 是成熟的企业生态和强大的运行时，它们为关键业务提供了最需要的稳定性和确定性。

有趣的是，Niko 自己也承认，这种“想法导向编程”的角色，与大公司的“首席工程师 (Principal Engineer)”非常相似。这引出了一个新的问题：过去，首席工程师的价值在于其丰富的经验和判断力。当 AI 让所有开发者都能像 PE 一样工作时，我们又该如何培养这种宝贵的判断力？

这或许是这场变革中，留给我们的最深刻的思考题。

Rust、Python、TypeScript 组成的“专家团队”或许是一条路，但 Go 这样的“全能瑞士军刀”和 Java 这样的“企业级航母”，也同样拥有无法被忽视的优势。

唯一可以确定的是，旧的格局正在被打破。而未来的编程语言版图，将由我们每一个开发者，用自己的项目和选择，共同绘制。

你认为，在 AI 的浪潮下，哪种语言或哪种特性，才是真正的未来？欢迎在评论区留下你的看法。

资料链接：https://smallcultfollowing.com/babysteps/blog/2025/07/31/rs-py-ts-trifecta

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

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

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

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

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

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

Go 的“身份危机”：当新 Gopher 试图将它变成他们最爱的语言

八月 12, 2025
0 条评论

本文永久链接 – https://tonybai.com/2025/08/12/go-identity-crisis

大家好，我是Tony Bai。

最近，在国外的 Go 社区（Reddit r/golang）上，一个帖子引发了我的深思。发帖者是一位资深的 Gopher，他用一种略带困惑的语气写道：

“我感受到来自新 Go 开发者的巨大压力，他们想把 Go 变成他们最喜欢的语言。”

他列出了一份“愿望清单”，上面是新 Gopher 们最常要求增加的特性：

注解 (Annotations)，像 Java 或 Python 那样
更多原生类型，比如 Set、Stream
三元运算符
元编程能力

同时，他还观察到了一些行为模式：引入大量依赖来完成简单的任务、用熟悉的 Java 式架构来封装地道的 Go 行为、甚至完全不使用强大的标准库……

这个帖子像一块石头投入了平静的湖面，瞬间激起了数百条评论。这不仅仅是一场关于“增加什么功能”的技术讨论，它更像是一场关于 Go 语言“我是谁？”、“我从哪里来？”、“我要到哪里去？”的哲学辩论。

这，正是 Go 语言正在经历的一场深刻的“身份危机”。

“原住民” vs “新移民”的哲学冲突

要理解这场危机的本质，我们可以把 Go 社区形象地看作一个正在迅速发展的“新大陆”。这里有两类居民：

“原住民” (The Natives)：他们是早期来到这片大陆的开拓者，被 Go 语言最初的承诺所吸引——简单、明确、可预测。他们选择 Go，正是因为它打破了传统语言不断堆砌特性、直到每个人都满意的怪圈。
“新移民” (The Immigrants)：随着 Go 的成功，大量来自 Java、Python、Ruby 等繁华“旧大陆”的开发者涌入。他们带来了丰富的经验和不同的编程习惯，同时也带来了对故乡那些“便利设施”的怀念。

这场冲突，本质上是“原住民”的简约哲学与“新移民”的表达力期望之间的碰撞。

“原住民”的坚守：可预测性是第一原则

对于老 Gopher 来说，Go 的核心价值在于它的可预测性。这意味着更少的“魔法”，更低的认知复杂度。

一篇评论精辟地指出：

“Go 想要的是一种更像扁平封装家具（flat pack furniture）的语言，而不是复杂的工程学。它追求的是：可预测、一致、简单、坚固。”

我们都知道，软件的 Bug 数量，往往不与代码行数（LOC）成正比，而是与认知复杂度成正比。Go 的哲学，就是宁愿增加一些可见的、重复的代码（比如经典的 if err != nil），也要换取认知复杂度的显著降低。当你阅读一段 Go 代码时，你所见即所得，几乎没有隐藏的控制流或隐式的行为。

这种对简单的极致追求，甚至延伸到了对标准库的设计上。为什么 Go 核心不内置一个 Set 类型？有评论认为，一旦官方内置，社区就会停止对这个问题的探索。而现在，虽然生态中可能有 50 种不兼容的 Set 实现，但这恰恰是生态系统该做的事情。语言核心应该保持绝对的稳定和精简，将多样性留给生态去繁荣。

“新移民”的期望：把这里也建成我的家乡

而来自 Java/Python 等生态的“新移民”，则带来了完全不同的期望。他们习惯了 Spring Boot 那种由注解驱动的、“魔法般”的依赖注入；习惯了 Python 丰富的原生数据结构和强大的表达力。他们认为这些特性是“生产力”的体现，是“现代语言的标配”。

于是，我们看到了各种“水土不服”的现象：

过度封装：试图用 Java 风格的仓储模式（Repository Pattern）、服务层（Service Layer）去封装 Go database/sql 这样简单直接的库，引入了不必要的复杂性和间接性。
依赖泛滥：为了实现一个简单的功能，引入一个庞大的框架或多个第三方库，而忽略了标准库中可能已经存在的、更简单的解决方案。
功能请愿：不断地在社区呼吁，希望 Go 能增加他们熟悉的各种语法糖和高级特性。

他们的初衷是好的——他们想“改进”Go，让它变得更“强大”、更“方便”。但问题在于，他们试图在 Go 这片追求极简主义的土地上，复刻他们熟悉的、那个充满了“便利设施”的家园。

这是一场“邪教”崇拜，还是一次理性的坚守？

在激烈的讨论中，一个尖锐的词被提及：“Go 社区有时感觉像个邪教（cult）。”

这个评价虽然刺耳，但也反映了外界对 Go 社区某种“固执”的不解。为什么 Go 开发者会对一些看似“能提升效率”的特性如此抗拒？

我认为，这并非“邪教”式的盲目崇拜，而是一种对设计哲学的深刻理解和理性坚守。

在 Go 之前，很少有主流语言如此旗帜鲜明地将简单性（Simplicity）和明确性（Explicitness）置于表达力（Expressiveness）和简洁性（Conciseness）之上。Go 的巨大成功，恰恰证明了这种看似“反潮流”的哲学，在构建大型、复杂、需要长期维护的系统中，具有无与伦比的价值。

正如发帖者所观察到的：Python 诞生于 1991 年，但著名的“Python 之禅”却是在 8 年后才被总结出来。而 Go，从诞生的第一天起，就带着极其强烈的哲学印记。它的设计者们，是在看尽了 C++ 等语言复杂性带来的痛苦后，才决心开辟一条返璞归真之路。

我们坚守的，不是某个具体的语法，而是这种让无数工程师受益的、来之不易的简单性。

解决方案与未来：我们该何去何从？

面对这场愈演愈烈的“身份危机”，我们该何去何从？我认为，答案不在于简单的“接受”或“拒绝”，而在于划定清晰的边界。

首先，要区分“语言核心”与“生态系统”。

语言核心必须保持稳定和简单。 这是 Go 语言的“护城河”，必须被坚定地守护。当然，这不意味着语言一成不变。像泛型（Generics）的引入，就是一个很好的例子。它虽然增加了语言的复杂性，但它解决了一个极其普遍且重要的问题，并且经过了社区长达十年的、极其审慎的讨论和设计。这种演进是可以接受的。但对于那些会引入“魔法”、破坏代码明确性的特性（比如注解驱动的依赖注入），则应该被坚决地挡在语言核心之外。
将“欲望”引导到生态系统。 “新移民”们对框架、对“电池”的需求是真实且合理的。但这些，应该由生态系统来满足。我们应该鼓励社区去构建像 Docker、Kubernetes 那样伟大的、遵循 Go 哲学的框架和产品，而不是反过来要求语言本身去迁就框架的设计。让那些喜欢 Spring 的人，去构建一个 Go 版本的、同样优秀的框架，而不是要求 Go 变成 Java。

其次，资深 Gopher 的责任，是“布道”而非“争吵”。

作为社区的“原住民”，我们的责任不仅仅是对那些可能破坏 Go 哲学的建议说“不”，更重要的是，要耐心地、清晰地向新 Gopher 们解释“为什么不”。

我们需要去传承 Go 的设计哲学，分享那些关于“少即是多”的深刻见解，讲述那些因为过度复杂而导致项目失败的“战壕故事”。这比单纯地争论某一个具体特性，对社区的健康发展更为重要。