前言
毫无疑问，在 2025 年，动态类型语言综合实力最强的就是 JavaScript。特别是在 2023 年 Bun.js 的正式版上线，更是巩固了这个结论。
技术论坛总喜欢跑分，而目前各种数据也确实证明了 JS 阵营已经达到了当前动态语言的性能天花板。
但问题来了：为什么这语言，却在当前最热门的 AI/数据科学领域，输给了 Python？
如果你纠结于跑分，你大概永远找不到答案。这场对决，早已超越了单纯的「谁快谁慢」，而是两种截然不同的**「设计哲学」** 导致的结果。
内卷与摆烂
如果你还对 JavaScript (Bun) 的性能实力抱有怀疑，请直接看下面的极端测试数据。这两张图测试的都是纯粹的 CPU 密集型运算，目的是衡量各种语言运行时本身的原始速度。
HTTP 服务器性能测试结果（相同配置电脑本地测试）
测试配置
- 测试时长: 60 秒
- 并发连接数: 100
- 测试工具: autocannon
- 响应内容: "hello world" (纯文本)
- 测试电脑: mac m4 16g
性能对比结果
| 排名 | 语言/运行时 | QPS (每秒请求数) | 平均延迟 | 总请求数 | 相对性能 |
|---|---|---|---|---|---|
| 🥇 | Bun | 144,563 | 0.04 ms | 8,674,000 | 100% |
| 🥈 | Node.js | 115,546 | 0.11 ms | 6,933,000 | 79.9% |
| 🥉 | Go | 83,478 | 0.91 ms | 5,009,000 | 57.7% |
| 4️⃣ | Python | 57,385 | 1.10 ms | 3,443,000 | 39.7% |
详细数据
🚀 Bun
- QPS: 144,563 请求/秒
- 平均延迟: 0.04 ms
- P99 延迟: 1 ms
- 总请求数: 8,674,000
- 吞吐量: 18.4 MB/s
🟢 Node.js
- QPS: 115,546 请求/秒
- 平均延迟: 0.11 ms
- P99 延迟: 1 ms
- 总请求数: 6,933,000
- 吞吐量: 20.6 MB/s
🐍 Python
- QPS: 57,385 请求/秒
- 平均延迟: 1.10 ms
- P99 延迟: 2 ms
- 总请求数: 3,443,000
- 吞吐量: 9.41 MB/s
🟦 Go (非动态类型语言，仅示例)
- QPS: 83,478 请求/秒
- 平均延迟: 0.91 ms
- P99 延迟: 2 ms
- 总请求数: 5,009,000
- 吞吐量: 9.43 MB/s
关键发现
- Bun 性能领先: 比 Node.js 快 25%，比 Python 快 152%
- 超低延迟: Bun 的平均延迟仅 0.04ms，是所有测试中最低的
- 稳定性: 所有服务器在 60 秒持续测试中表现稳定
- Go 表现: Go 作为静态语言，性能介于 Node.js 和 Python 之间
从上面的测试可以看到，BunJs 的执行性能平均都是 纯 Pyhton 的 几十倍，而 http 性能也远超 python。
伪装的静态类型 TypeScript
我们已经用数据证明了 JavaScript (Bun) 在速度上的统治力。但速度，从来不是工程决策的唯一标准。
如果说 Bun 是 JavaScript 在「性能内卷」上的极致表现，那么 TypeScript 的流行，就是 JavaScript 在「工程可靠性」上的最大「认输」。
TypeScript 的本质，是对 JavaScript 原始语言哲学（动态、宽松）的 一种纠正 。
它强迫开发者在编译时（或者说，在开发阶段）就遵循静态型别的规则，从而提前抓到 90% 的类型错误。
这是一种**「亡羊补牢」的工具，让 JavaScript 代码在可靠性**上似乎能勉强追上 C/C++ 这种天生静态类型的语言。
换句话说：JavaScript 必须**「自废武功」、「戴上镣铐」，才能在工程可靠性上获得入场券。**
设计哲学
我们将目光移到两个语言的开端，这场对决的命运，或许早已在诞生之初就被决定了。
语言诞生时间与设计初衷
| 语言 | 诞生时间 | 设计初衷 |
|---|---|---|
| JavaScript | 1995 年 | 小而精的网页脚本语言 |
| Python | 1991 年 | 方便地调用 C/C++ 模组的胶水语言 |
这两种不同的决策思路，导致了语言在未来有著不同的宿命：
📈 Python 的哲学：战略性外包
Python 的设计者 Guido van Rossum 知道 Python 语言本身在纯运算上可能不够快，但没关系。
它的哲学：
- 它不需要亲自做那些慢速、复杂、对性能要求高的工作。
- 它只负责调度。
它的策略：
- 它将所有对速度和稳定性有要求的任务，战略性的外包给了 C/C++ 等编译型语言。
这就是为什么在 CPU 密集型跑分中 Python 敢于「摆烂」：因为核心战场上的运算，根本就不是由 Python 本身来跑的。
得益于长时间的发展，现在你随便 import 一个 python 包，可能内部就是 C/C++之类的语言写的。
📉 JavaScript 的宿命：全能的内卷
而 JavaScript 的路则艰难得多。
它的限制：
- 受限于网页的**「沙盒」机制，JS 无法像 Python 那样随意调用外部系统库**。
- 即使到了 Node.js 时期，遵循着早先的习惯， JS 阵营依然不愿意大规模胶水别的语言。
不愿意的原因：
- 引入 C/C++ 扩展会极大地增加**「跨平台」和「版本兼容」的维护成本**，这会摧毁 JS 「一次编写，到处运行」的准则。
它的宿命：
- 它必须亲力亲为地完成所有工作，靠自己的引擎（V8/Bun）进行极致的「内卷」，才能勉强达到高性能。
因为 JavaScript 的谨慎，如今你随便 import 一个包，大概率还是 Js 写的。
胶水与被胶水
这两种设计哲学，再加上生态的发展，最终在工程体系中演化成了一场**「谁在胶水谁」的对决。如果将编程世界视为一间公司，Python 绝不是那个跑得最快的「基层程序员」**，它是：
👑 Python：掌控决策权的「外包总监」
Python 始终掌握著**「调度」**的权力。
它的权力： 它决定了何时将数据扔给底层 C++ 执行，何时又将结果收回。它不必在乎 C++ 的编译流程有多复杂，只需享受其性能和型别安全的红利。
它的战场： AI、数据分析——这些是企业的**「决策层」业务。Python 的角色是高层次的逻辑协调者**，将所有脏活累活外包出去，风险转嫁。
🐂 JavaScript：全能内卷的「基层老黄牛」
而 JavaScript，尽管性能强大（Bun 的速度摆在那里），却始终在扮演**「执行者」和「通用工具人」**的角色。
它的命运： 它必须在各种宿主环境（浏览器、App 壳、Node.js 伺服器） 下，亲力亲为地处理所有的 I/O 和页面逻辑。
它的战场：所有地方都可见它的身影，这不就是基层员工？
也就是说，我们在用 python 时，大概率用的不是 python 本身，但我们在用 JavaScript 时，大概率用的就是其语言本身。
最后
最近，Bun.js 被 Anthropic 公司（Claude 模型的开发商）收购了。作为开源项目，被收购是件好事，这也是开源项目的一种商业模式。
但是，凡事都有利弊：
对开源的「好处」
-
资金与资源： Anthropic 提供了稳定的资金和资源，能让 Bun 团队更专注于核心开发，不必再为商业模式烦恼。
-
战略背书： 被一家顶级 AI 公司选中，证明了 Bun 在 I/O、启动速度等工程基建上的价值是行业领先的。
-
行业扩展： Bun 的性能将被应用于 AI 应用（Claude）的底层交付，这为 JS 阵营开辟了新的应用场景。
对社区的「风险」
-
目标收窄： 尽管 Bun 依然开源，但其发展方向可能更倾向于服务于 Anthropic 的商业目标（例如 AI 应用部署、模型推理优化），而不是纯粹服务于广泛的 Web 社区，可能会导致偏离 Js 本身。
-
社区话语权： 社区提案和贡献的重要性可能会降低，技术决策权会高度集中于公司内部，也就是创作团队会变成乙方。
但是不管怎么样，这目前都是一个利好消息，这有助于扩大 zig 社区的影响力，对创作团队也是一个好事！
可喜可贺可喜可贺！
