前言
毫無疑問，在 2025 年，動態類型語言綜合實力最強的就是<span style="color: red;font-size: 16px"> JavaScript</span>。特別是在 2023 年 Bun.js 的正式版上線，更是鞏固了這個結論。
技術論壇總喜歡跑分，而目前各種數據也確實證明了 JS 陣營已經達到了當前動態語言的性能天花板。
但問題來了：<span style="color: red;font-size: 16px">為什麼這語言，卻在當前最熱門的 AI/數據科學領域，輸給了 Python？</span>
如果你糾結於跑分，你大概永遠找不到答案。這場對決，早已超越了單純的「誰快誰慢」，而是兩種截然不同的「設計哲學」 導致的結果。
內卷與擺爛
如果你還對<span style="color: red;font-size: 16px"> JavaScript (Bun) </span>的性能實力抱有懷疑，請直接看下面的極端測試數據。這兩張圖測試的都是純粹的 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 之間
從上面的測試可以看到，<span style="color: red;font-size: 16px">BunJs 的執行性能平均都是 純 Pyhton 的 幾十倍，而 http 性能也遠超 python。</span>
偽裝的靜態類型 TypeScript
我們已經用數據證明了 JavaScript (Bun) 在速度上的統治力。但速度，從來不是工程決策的唯一標準。
如果説 Bun 是 JavaScript 在「性能內卷」上的極致表現，那麼 TypeScript 的流行，就是 JavaScript 在「工程可靠性」上的最大「認輸」。
TypeScript 的本質，是對 JavaScript 原始語言哲學（動態、寬鬆）的 <span style="color: red;font-size: 16px">一種糾正</span> 。
它強迫開發者在編譯時（或者説，在開發階段）就遵循靜態型別的規則，從而提前抓到 90% 的類型錯誤。
這是一種「亡羊補牢」的工具，讓 JavaScript 代碼在可靠性上似乎能勉強追上 C/C++ 這種天生靜態類型的語言。
換句話説：JavaScript 必須「自廢武功」、「戴上鐐銬」，才能在工程可靠性上獲得入場券。
設計哲學
我們將目光移到兩個語言的開端，這場對決的命運，或許早已在誕生之初就被決定了。
語言誕生時間與設計初衷
| 語言 | 誕生時間 | 設計初衷 |
|---|---|---|
| JavaScript | 1995 年 | 小而精的網頁腳本語言 |
| Python | 1991 年 | 方便地調用 C/C++ 模組的膠水語言 |
這兩種不同的決策思路，導致了語言在未來有著不同的宿命：
📈 Python 的哲學：戰略性外包
Python 的設計者 Guido van Rossum 知道 Python 語言本身在純運算上可能不夠快，但沒關係。
它的哲學：
- 它不需要親自做那些慢速、複雜、對性能要求高的工作。
- 它只負責調度。
它的策略：
- 它將所有對速度和穩定性有要求的任務，戰略性的外包給了 C/C++ 等編譯型語言。
這就是為什麼在 CPU 密集型跑分中 Python 敢於「擺爛」：因為核心戰場上的運算，根本就不是由 Python 本身來跑的。
<span style="color: red;font-size: 16px">得益於長時間的發展，現在你隨便 import 一個 python 包，可能內部就是 C/C++之類的語言寫的。</span>
📉 JavaScript 的宿命：全能的內卷
而 JavaScript 的路則艱難得多。
它的限制：
- 受限於網頁的「沙盒」機制，JS 無法像 Python 那樣隨意調用外部系統庫。
- 即使到了 Node.js 時期，遵循着早先的習慣， JS 陣營依然不願意大規模膠水別的語言。
不願意的原因：
- 引入 C/C++ 擴展會極大地增加「跨平台」和「版本兼容」的維護成本，這會摧毀 JS 「一次編寫，到處運行」的準則。
它的宿命：
- 它必須親力親為地完成所有工作，靠自己的引擎（V8/Bun）進行極致的「內卷」，才能勉強達到高性能。
<span style="color: red;font-size: 16px">因為 JavaScript 的謹慎，如今你隨便 import 一個包，大概率還是 Js 寫的。</span>
膠水與被膠水
這兩種設計哲學，再加上生態的發展，最終在工程體系中演化成了一場「誰在膠水誰」的對決。如果將編程世界視為一間公司，Python 絕不是那個跑得最快的「基層程序員」，它是：
👑 Python：掌控決策權的「外包總監」
Python 始終掌握著「調度」的權力。
它的權力： 它決定了何時將數據扔給底層 C++ 執行，何時又將結果收回。它不必在乎 C++ 的編譯流程有多複雜，只需享受其性能和型別安全的紅利。
它的戰場： AI、數據分析——這些是企業的「決策層」業務。Python 的角色是高層次的邏輯協調者，將所有髒活累活外包出去，風險轉嫁。
🐂 JavaScript：全能內卷的「基層老黃牛」
而 JavaScript，儘管性能強大（Bun 的速度擺在那裏），卻始終在扮演「執行者」和「通用工具人」的角色。
它的命運： 它必須在各種宿主環境（瀏覽器、App 殼、Node.js 伺服器） 下，親力親為地處理所有的 I/O 和頁面邏輯。
它的戰場：所有地方都可見它的身影，這不就是基層員工？
<span style="color: red;font-size: 16px">也就是説，我們在用 python 時，大概率用的不是 python 本身，但我們在用 JavaScript 時，大概率用的就是其語言本身。</span>
最後
最近，Bun.js 被 Anthropic 公司（Claude 模型的開發商）收購了。作為開源項目，被收購是件好事，這也是開源項目的一種商業模式。
但是，凡事都有利弊：
對開源的「好處」
- 資金與資源： Anthropic 提供了穩定的資金和資源，能讓 Bun 團隊更專注於核心開發，不必再為商業模式煩惱。
- 戰略背書： 被一家頂級 AI 公司選中，證明了 Bun 在 I/O、啓動速度等工程基建上的價值是行業領先的。
- 行業擴展： Bun 的性能將被應用於 AI 應用（Claude）的底層交付，這為 JS 陣營開闢了新的應用場景。
對社區的「風險」
- 目標收窄： 儘管 Bun 依然開源，但其發展方向可能更傾向於服務於 Anthropic 的商業目標（例如 AI 應用部署、模型推理優化），而不是純粹服務於廣泛的 Web 社區，可能會導致偏離 Js 本身。
- 社區話語權： 社區提案和貢獻的重要性可能會降低，技術決策權會高度集中於公司內部，也就是創作團隊會變成乙方。
但是不管怎麼樣，這目前都是一個利好消息，這有助於擴大 zig 社區的影響力，對創作團隊也是一個好事！
可喜可賀可喜可賀！
本文由mdnice多平台發佈
