[Tempest Rust Daily] 技術情報精華 (2026-10-06) – 深度完整版

本期精選 Rust 在 Web 開發、非同步執行、跨語言整合與開發工具鏈上的最新動向,並關注 mold 以 Rust 重寫、嵌入式圖形資料庫,以及 Kubernetes MCP 伺服器等實務案例。

Web 開發不一定需要 WebAssembly

文章重新檢視 Rust Web 應用與 WebAssembly 的關係,指出採用 Rust 並不代表所有頁面都必須做成 WebAssembly 應用。真正需要判斷的是哪些使用情境能從 WASM 獲益,以及何時使用傳統伺服器端架構會更合適。

https://ift.tt/K0ZSfVM

Ramen:面向多可用區 Kubernetes 的 MCP 伺服器

Ramen 是可自行託管的多可用區 MCP 伺服器,鎖定 GCP 與 AWS 上的 Kubernetes 環境。其架構結合 Rust MCP 節點與 Python 3.14 執行工作程序,邊緣介面採用 Streamable HTTP,內部通訊則使用 gRPC,並透過 FastAPI 管理介面進行操作。

https://ift.tt/mSp1q9g

從單態化理解 Rust 泛型的編譯方式

這篇入門文章介紹 Rust 的單態化(monomorphization):編譯器會依泛型實際使用的型別產生對應程式碼。這個概念有助於初學者理解 Rust 如何在提供泛型抽象的同時,產生針對具體型別編譯的執行結果。

https://ift.tt/JT9L0jX

Relaxnative 簡化 Node.js 原生程式碼整合

Relaxnative 讓 Node.js 應用直接載入以 C、C++、Rust、Zig 或 Go 撰寫的函式。開發者可將原始碼檔交給 loadNative(),首次匯入時完成編譯,並依內容快取結果,不必自行維護 node-gyp、binding.gyp 或手寫 N-API 銜接程式碼。

https://ift.tt/H5jPW6L

Mago 以單一 Rust 工具整合 PHP 程式碼品質檢查

Mago 嘗試以單一 Rust 執行檔涵蓋 PHP 的格式化、靜態分析、程式碼檢查與品質防護工作,定位上可取代 PHP-CS-Fixer、PHPStan 等多套工具。文章也說明如何設定這套工具鏈,讓 PHP 專案以較一致的流程執行檢查。

https://ift.tt/CpjPSG3

Aspire 13.6 加入 Rust 一級支援的託管套件

Aspire 13.6 推出預覽版 Java 與 Rust 託管套件,並讓儀表板以 SQLite 保存遙測資料,每個應用程式最多保留十次已完成的執行紀錄。其他更新包括可攜式儲存卷路徑與新的 CLI 選項;升級時則需留意本機 MongoDB 自動啟用 TLS 等破壞性變更。

https://ift.tt/aQJRijn

改善 Rust CLI 工具的當機報告體驗

這篇文章以生物資訊管線工具 Rastair 為背景,探討如何替 Rust 命令列程式製作更友善的當機報告。對經常在自動化管線內執行的 CLI 而言,清楚呈現錯誤脈絡,有助於使用者在設定或執行失敗時更快定位問題。

https://ift.tt/svjAPy3

Minigraf:支援雙時間模型的嵌入式圖形資料庫

Minigraf 是以 Rust 開發的自包含圖形資料庫,主打 AI 代理程式、行動應用與瀏覽器等嵌入式情境。它提供 Datalog 查詢與雙時間(bi-temporal)歷史追蹤,目標是以類似 SQLite 的部署方式,處理具有關聯與完整變更歷程的資料。

https://ift.tt/fZu1d42

mold 3.0 完成從 C++ 到 Rust 的重寫

高速連結器 mold 發布 3.0.0,這是專案從 C++ 重寫為 Rust 後的首個版本。官方先前已說明 2.42.1 是最後一個 C++ 版本,因此 3.0 也代表 mold 正式跨入以 Rust 為主要實作的新階段。

https://ift.tt/xscCTMo

非同步 Rust 的排程器究竟位於哪一層?

文章從常見的 async Rust 爭議切入,聚焦排程器在非同步執行模型中的位置。這是理解 Rust 非同步機制的重要問題,牽涉語言本身、Future 抽象與執行環境之間如何分工,也能幫助開發者釐清 async 語法與實際任務排程並非同一層次。

https://ift.tt/EZ8PRSW

Rust 成為現代 Python 工具鏈的重要底層引擎

文章整理 Ruff、uv、Pydantic 與 Polars 等 Python 生態工具採用 Rust 的趨勢,探討這類跨語言架構為何逐漸普及,以及它對 Python 開發工具的意義。Rust 在此扮演底層實作角色,同時保留 Python 使用者熟悉的操作介面。

https://ift.tt/IpuSDyT

[Tempest Rust 深度解讀] CPython 探索把 Rust 寫進核心:不只是取代 C 的安全實驗 (2026-10-06)

「CPython 要用 Rust 取代 C」是醒目的說法,卻不是目前最精確的結論。現階段更接近一項有路線圖、有實作原型,但仍待 PEP 審議的漸進式實驗:先讓少數標準函式庫元件能選用 Rust 實作,保留既有 C 路徑,再用效能、平台支援與維護成本決定是否擴大。

事件走到哪一步

WebProNews 報導將此事描述為 Python 核心開發團隊探索把 Rust 直接整合進 CPython,以改善記憶體安全與維護性:https://www.webpronews.com/python-core-team-explores-rust-integration-to-replace-c-code-in-cpython/。方向大致正確,但文中談到記憶體配置器、資料結構、內建函式乃至「方向已確立」等內容,不能全部視為已通過的官方計畫。

已確認的事實是:Python 官方部落格記錄的 2026 Python Language Summit 提案,預定在 2026 年底以 PEP 定義成功標準;最早於 Python 3.16、也就是預定 2027 年 10 月發布的版本,加入可選的 Rust zlib 實作及私有 Rust API,原有 C 實作仍作為備援。Rust 最早要到 Python 3.18、亦即 2029 年,才可能成為建置 CPython 的必要條件,而且這仍只是提議中的時程:https://blog.python.org/2026/09/language-summit-2026-rust-for-cpython/。

不是重寫,而是建立第二條實作路徑

提案的技術核心,是讓 Rust 元件透過外部函式介面與 CPython 既有物件模型互動。Rust API 概念稿以智慧指標包裝 Python 物件,將執行緒與直譯器狀態明確傳入函式,並利用作用域結束時自動釋放資源。這能降低忘記清理記憶體或錯誤操作參照計數的機率,但跨越 Rust 與 C 的邊界仍需要審慎設計,並不會因為換了語言就自動沒有漏洞。

第一個候選項目是 zlib,原因不是它位於直譯器最深處,而是範圍小、容易保留 C 備援,又廣泛影響 Python 套件的壓縮與解壓縮。提案計畫採用 zlib-rs,並以幾乎每次套件安裝都可能受益作為實際價值。不過這項效益仍須由真實工作負載驗證,不能把個別平台的壓縮基準直接等同於所有 pip install 都會明顯加速。

另一個容易混淆的進展是:CPython 主線開發文件已列出 --with-zlib=zlib-rs,也能選擇 Rust 實作的 bzip2 相容函式庫:https://github.com/python/cpython/blob/main/Doc/using/configure.rst。這證明建置系統已能連結部分以 Rust 實作、但提供 C 相容介面的後端;它仍不等於 Rust 模組已正式進入 CPython 核心,更不代表相關 PEP 已獲接受。

為何現在值得注意

這項計畫真正重要之處,不是 C 與 Rust 的語言競賽,而是 CPython 是否願意成為長期的雙語言專案。官方四月進度報告顯示,實驗分支已在其測試涵蓋的平台上通過含 Rust 的 CI,目標也從 Python 3.15延後到 3.16,以預留 API 設計與審議時間:https://blog.python.org/2026/04/rust-for-cpython-2026-04/。

合理推論是:若小型元件能證明安全性與效能收益大於新增工具鏈的成本,io、json、xml、memoryview 與 parser 等領域才可能成為後續候選。反之,若發行版、交叉編譯或冷門平台承受過高負擔,Rust 也可能長期停留在選配層。這是一套以實證換取擴張資格的制度設計,而非全面重寫的起點。

實際影響與容易忽略的限制

  • 一般 Python 使用者:短期幾乎不必採取行動。Python 3.16 的 Rust 路徑若獲准,初期仍是選配,語言語法與既有 Python 程式不會因此改變。
  • 發行版與自行建置者:影響較早出現。Rust 編譯器版本、原始碼供應、離線建置、交叉編譯、CI 時間與漏洞修補責任,都會進入維護清單。
  • C 擴充套件作者:目前沒有 C API 即將被撤換的依據。私有 Rust API 的首要使用者是 CPython 本身;公開 Rust API 在提議路線中要到更後期才會出現。
  • 核心維護者:收益是部分記憶體安全錯誤可在編譯期被攔下;代價則是審查者必須理解兩種語言,以及 FFI、參照計數與直譯器狀態三者的交互作用。

供應鏈也是雙面刃。語言層級的安全保證可以縮小部分攻擊面,但引入 Cargo 套件同時增加依賴治理工作。官方峰會紀錄提到,核心開發者已將依賴來源、vendoring 與安全事件後的重發版成本列為可能的「阻斷點」。因此,把 Rust 簡化為「更安全,所以一定值得」並不足以支撐決策。

對台灣開發團隊的意義

多數透過作業系統套件、容器映像或雲端平台取得 Python 的台灣團隊,最初只會感受到發行者選定的結果。真正需要提早關注的,是自行編譯 CPython、維護企業內部映像、支援 ARM 或嵌入式設備,以及製作跨平台二進位套件的團隊。它們應把 Rust 工具鏈納入試驗性 CI,但現在就改寫既有 C 擴充套件,並沒有充分依據。

作者觀點是:最值得肯定的不是 Rust 本身,而是提案保留 C 備援、延後強制採用,並要求以核心開發者接受度、效能無明顯退步、所有分級平台可用及發行者回饋作為門檻。對一個承載龐大科學運算、AI 與企業系統生態的直譯器而言,可撤回的漸進實驗比一次性重寫更有價值。

接下來應看哪些指標

  • 正式 PEP 是否提交、其狀態及成功標準是否可量測。
  • Python 3.16 是否真的納入可選 Rust 模組,而不只是接受外部 Rust 函式庫。
  • zlib-rs 在套件安裝、記憶體用量與多平台測試中的實測結果。
  • CPython 各分級平台、Linux 發行版、Windows 與交叉編譯環境的建置回報。
  • 外部 crate 的選擇、封存、漏洞回應及離線重現建置政策。
  • Rust API 何時從私有介面走向公開承諾,以及 C API 是否出現實際棄用提案。

因此,現階段最準確的判讀不是「Python 核心將由 Rust 取代 C」,而是「CPython 正準備用一個可選、可比較、可回退的 Rust 路徑,測試雙語言核心是否值得長期維護」。真正的分水嶺將是 PEP 的審議與 Python 3.16 的落地結果,而不是二手報導中的宣示。

[Tempest Rust Daily] 技術情報精華 (2026-10-07) – 深度完整版

本期聚焦 Rust 生態系的工具鏈、跨語言互通、桌面應用、圖形渲染與學習資源,也收錄效能最佳化及程式碼體積等實務議題。

Mold 3.0 以 Rust 重寫高速連結器

Mold 3.0 將原本以 C++ 開發的高速連結器改以 Rust 重寫,並以可直接替代既有版本為目標。專案亦希望進一步成為 Linux 平台的預設連結器,值得關注其相容性、效能表現與導入情況。

[https://ift.tt/BXNjzy4]

deno_lint:可嵌入的 JavaScript 與 TypeScript lint 引擎

deno_lint 是用來建構 JavaScript 與 TypeScript linter 的 Rust crate,也是 Deno 內建 lint 指令採用的核心引擎。它並未與 Deno 執行環境綁死,因此可整合至其他開發工具或自訂靜態分析流程。

[https://ift.tt/TveiVA9]

Rust 與 C++ 的安全性及互通挑戰

這場討論從不同類型的「安全性」切入,分析 Rust 與 C++ 各自能提供哪些保證,以及兩種語言互通時面臨的限制。內容也探討 C++ 邁向記憶體安全的可能路徑,適合關注既有 C++ 系統漸進導入 Rust 的團隊。

[https://ift.tt/MyZ4QBE]

別讓基準測試誤導 Rust 最佳化

影片以 ripgrep 為案例,檢視 AI agent 對正式 Rust 程式碼提出的三項效能修改及其基準測試結果。重點包括如何辨識只對測試案例有利的「benchmark gaming」,以及為何最佳化成果仍需透過合理工作負載與嚴謹量測驗證。

[https://www.youtube.com/watch?v=E4lmBchwGHc]

從單態化理解 Rust 程式碼膨脹

文章延續 Rust 單態化主題,說明泛型程式碼如何針對不同具體型別產生個別實作,以及這項機制為何可能增加編譯後的程式碼體積。這是理解 Rust 泛型效能優勢與二進位檔大小取捨的入門材料。

[https://ift.tt/qOCdx3g]

以 wgpu 與 winit 建立可重用的 WebGPU 引擎

系列首篇示範如何用 Rust、wgpu 與 winit 規劃輕量且模組化的渲染架構。設計核心是拆分 CPU 端應用邏輯與 GPU 渲染管線,為後續擴充模擬器或跨平台圖形應用建立較清楚的邊界。

[https://ift.tt/nlgeWMY]

Tauri、React 與 Rust 打造離線優先採購工作區

這篇實作文章探討如何以 Tauri、React 與 Rust 建構原生採購工作區,並將離線優先納入整體架構。相較純 Web 應用,桌面端方案可針對本機資料與離線作業需求設計,同時保留前端框架的開發模式。

[https://ift.tt/k5aWryA]

RXScan 整合網路偵察與 OSINT 工作流程

RXScan 是以 Rust 開發的開源偵察工具,最初定位為網路掃描器,之後逐步擴充為更完整的 recon 工作流程。它著重保存及關聯網路觀察、公開來源調查結果與其他證據,目前作者也在徵求實際測試與意見回饋。

[https://ift.tt/WVYtH7w]

用像素風遊戲一路學完《The Rust Programming Language》

Ferris’ Forge 是一款在瀏覽器執行的 Rust 學習遊戲,課程安排依循《The Rust Programming Language》的內容推進。作者以島嶼與遊戲關卡包裝學習流程,提供傳統文件閱讀之外的互動式選擇。

[https://ift.tt/FJVzWc3]

Rust 宣告式巨集實用入門

這篇教學介紹 Rust 宣告式巨集的基礎語法與常用術語,並涵蓋巨集衛生等重要概念。對準備以 macro_rules! 減少重複程式碼,或希望讀懂現有 crate 巨集實作的開發者而言,可作為入門起點。

[https://ift.tt/gcoy3NU]

在 Raspberry Pi 上開始學習 Rust

這份教學清單面向擁有 Raspberry Pi 的 Rust 初學者,整理環境建置、語言基礎與開始製作專案所需的資源。對想把 Rust 學習結合單板電腦與個人實作的讀者,是一條較具體的起步路線。

[https://ift.tt/FQlkHx1]

Vyasa:以 Rust 開發的替代 CMS

Vyasa 是一項以 Rust 建構替代內容管理系統的開源專案。對正在評估 WordPress 之外方案,或希望研究 Rust 在內容管理與網站後端應用方式的開發者,可從其原始碼與專案設計進一步了解。

[https://ift.tt/suMeqbY]

[Tempest Rust Daily] 技術情報精華 (2026-10-04) – 深度完整版

本期整理 11 則 Rust 技術動態,涵蓋 Linux 發行版與工具鏈維護、編譯器後端、跨語言整合、遊戲 AI、資料庫工具及開發者社群討論。

Ubuntu 26.10 Beta 導入 Linux 7.3、GNOME 51 與 Rust Coreutils

Canonical 已釋出代號「Stonking Stingray」的 Ubuntu 26.10 Beta,預計在 2026 年 10 月 15 日推出正式版。這個測試版本整合 Linux 7.3、GNOME 51 與以 Rust 實作的 Coreutils,適合開發者及系統管理員提前檢視新版桌面環境、核心與基礎命令列工具的相容性。[https://ift.tt/TceMVfG]

Rust 上游工具鏈維護進度報告

Rust 開源工具鏈維護者發布 2026 年 8 月至 9 月的工作報告,延續每兩個月一次的紀錄,說明其以 Sovereign Tech Fellow 身分參與上游維護的進展。對關心 Rust 編譯器與工具鏈長期維護工作的讀者而言,這份報告提供了第一手的專案脈絡。[https://kobzol.github.io/rust/2026/09/30/stf-august-september-2026.html]

從泛型與 Codegen Units 觀察 Rust 傳給 LLVM 的程式碼

文章接續先前對 MIR 的解析,進一步探討 Rust 編譯流程如何從中介表示走向 LLVM。內容聚焦泛型與 Codegen Units,協助讀者理解編譯器如何拆分程式、產生交給 LLVM 的內容,以及這些機制在程式碼生成階段扮演的角色。[https://ift.tt/AkpJ13s]

fast_xlsx:以 Rust 加速 Ruby 的 Excel 寫入

fast_xlsx 是用來從 Ruby 產生 .xlsx 檔案的原生擴充套件,底層透過 Magnus 串接 rust_xlsxwriter,API 則以 fast_excel 為起點。目前版本為 0.8,作者正在正式邁向 1.0 前徵求測試者,特別適合關注 Ruby 與 Rust 跨語言整合或大量試算表輸出的開發者。[https://ift.tt/kuFbhxy]

用 Bitboard 與 Alpha-Beta Pruning打造高效回合制遊戲 AI

這篇文章以 Rust 與 Go 探討回合制棋盤遊戲 AI,將 Bitboard 棋盤表示法與 Alpha-Beta Pruning 搜尋策略結合。主題聚焦如何在嚴格的互動延遲限制下增加搜尋深度,可作為西洋棋、西洋跳棋、國際跳棋及西洋雙陸棋等遊戲引擎的實作參考。[https://ift.tt/jUoHLbh]

Python 核心開發社群持續討論 Rust 的定位

David Hewitt 在 2025 年 PyCon US 初步探詢意見後,再度於 2026 年 Python Language Summit 與核心開發者討論 Rust。焦點從「是否採用」逐漸轉向 CPython 開發者實際希望 Rust 解決哪些問題,反映跨語言導入除了技術可行性,也需要釐清維護方式與社群需求。[https://ift.tt/vS32Z1t]

Klyndb:以 Rust 與 Tauri 打造的開源資料庫用戶端

Klyndb 是一款以 Rust 與 Tauri 建構的免費開源資料庫用戶端,定位為 DBeaver 的替代方案。專案強調不使用 Electron、不要求帳號、不強制依賴雲端服務,也不收集查詢遙測資料,訴求更輕量且偏向本機操作的資料庫工作流程。[https://ift.tt/8HTkD67]

完全在終端機執行的 Local-first AI 程式開發代理

社群分享一款以 Rust 開發、完全在終端機內運作的 Local-first AI 程式開發代理。專案將本機優先的使用模式與命令列工作流程結合,適合關注 Rust CLI 應用、AI 輔助開發工具,以及希望減少對圖形介面或遠端服務依賴的開發者追蹤。[https://ift.tt/e436imJ]

Microsoft 將 Rust 列為內部 Tier-1 程式語言

Microsoft 已將 Rust 提升為內部開發的 Tier-1 程式語言,與 C++、C# 及 TypeScript 同列公司支援程度最高的語言。這裡的 Tier-1 指 Microsoft 內部分級,並非 Rust Project 的平台支援層級;此變化代表 Microsoft 團隊採用 Rust 時可獲得更正式的內部支援。[https://ift.tt/Hg2SfNj]

Rust 社群短影音:Through Rust all things are possible

這支 YouTube Shorts 以「Through Rust all things are possible」為題,用短影音形式呈現 Rust 相關內容。雖然提供的說明未揭露更多技術細節,但可作為觀察 Rust 社群文化與影音傳播方式的一則輕量素材。[https://www.youtube.com/shorts/5A3vQbkUsaU]

社群辯論:為什麼重寫專案時總是選 Rust,而不是 Go?

一則社群討論質疑,為何 LLM 相關的專案重寫經常優先選擇 Rust,而非 Go。發文者認同 Rust 在部分情境下具有效能優勢,但也指出 Go 在網路應用、編譯時間與標準函式庫方面的吸引力;這項討論呈現選擇系統程式語言時,效能、開發效率與生態系之間的取捨。[https://ift.tt/kZbpFx9]

[Tempest Rust 深度解讀] Rust 會進入 CPython 核心嗎?語言高峰會開始討論真正的邊界 (2026-10-04)

這仍是一項提案,不是 CPython 已決定改寫

2026 年 Python Language Summit 的關鍵進展,不是「Python 將改用 Rust」,而是核心開發者開始討論:Rust 必須證明什麼,才有資格從實驗工具變成 CPython 的長期組成。依 Python 官方紀錄,Rust for CPython 團隊約有 60 名參與者,由 CPython 核心開發者 Kirill Podoprigora、Emma Smith 等人推動;規劃中的第一步,是在 Python 3.16 提供完全選用的 Rust 實作,既有 C 程式碼仍作為備援。最早可能要求 Rust 才能建置 CPython,則被放在 2029 年的 Python 3.18,且仍取決於後續 PEP 與驗收結果。來源:https://blog.python.org/2026/09/language-summit-2026-rust-for-cpython/

來源事實是:會議提出了路線圖、成功條件與候選模組,但尚未形成「Rust 必然進入核心」的決議。把這場討論寫成 CPython 即將全面改寫,會忽略 Python 的 PEP 治理、平台承諾及發行商測試仍在前方。

運作邏輯:先從可替換、可退回的小邊界開始

團隊選擇 zlib 作為第一個候選項目,原因是範圍小,卻能一次驗證建置系統、C/Rust 互通、外部 crate 管理、效能與跨平台支援。構想不是把直譯器主迴圈立刻搬到 Rust,而是讓標準函式庫的 zlib 模組可選用 zlib-rs;若環境不支援,仍可使用 C 版本。

Rust API 的草圖則把執行緒與直譯器狀態明確傳入函式,以智慧指標管理 Python 物件,並用 Result 表達成功或錯誤。緩衝區可在作用域結束時自動釋放,減少 C 程式碼中容易遺漏的手動清理。然而這只能消除部分記憶體管理風險,不能保證演算法正確,也不能自動解決跨語言邊界、並行狀態或不安全程式碼的問題。

一個容易混淆但重要的交叉驗證是:CPython 主分支的 3.16 建置文件已列出 --with-zlib=zlib-rs,可讓 zlib 模組連結外部 zlib-rs 的 C 相容介面;預設仍優先使用系統 zlib。這證明 zlib-rs 已能在「替代底層函式庫」這一層被測試,但不等於 CPython 已接受內建 Rust 工具鏈、私有 Rust API或未來的公開 API。兩者的治理成本並不相同。官方文件:https://github.com/python/cpython/blob/main/Doc/using/configure.rst

為何現在值得注意

CPython 同時推進新解析器、JIT 與 free-threading,底層狀態管理愈來愈複雜。峰會簡報指出,標記為崩潰類型的議題近年增加,因此提案者希望把 Rust 當成降低特定錯誤類別的工程手段,而不是流行語言換裝。

這個方向並非沒有外部經驗支持。Google 在 Android 13 的回顧中表示,2019 至 2022 年記憶體安全漏洞由 223 件降至 85 件,同期新程式碼逐步轉向 Java、Kotlin 與 Rust;Google 也明確提醒這是相關性而非單一因果證明。這項案例支持「對新程式碼採用記憶體安全語言」的方向,卻不能直接推導 CPython 會得到相同比例的改善。來源:https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

實際影響可能先出現在套件安裝

提案者主張,更快的 zlib 實作可能加速大量 pip install。這項說法有合理基礎:wheel 本質上是 ZIP 壓縮檔,安裝流程包含解壓縮;格式規格可見 https://packaging.python.org/en/latest/specifications/binary-distribution-format/。但「幾乎每次安裝都變快」仍應視為待測假說。總時間也受網路、依賴解析、雜湊驗證、檔案系統與位元組碼編譯影響,而且只有實際採用該後端的 Python 發行版才會受益。

合理推論是:zlib 的真正價值不只在壓縮速度,而是它能用低風險、可比較的工作負載,回答「安全收益是否值得新增第二套語言與工具鏈」這個更大的問題。

最容易被忽略的是發行與維護成本

第一項限制是平台交集。CPython 與 Rust 都採分級支援,但保證並不完全相同;Rust 的 Tier 2 通常只保證可建置,不保證每次變更都完整執行測試。其平台政策可見 https://doc.rust-lang.org/nightly/rustc/platform-support.html。若 CPython 要求所有既有分級平台都能使用 Rust,發行商、交叉編譯環境及較少見架構就會成為真正的驗收關卡。

第二項是供應鏈。CPython 對外部相依套件一向保守;即使以 vendor 方式固定 Rust 原始碼、讓建置時不需連線 Cargo,也沒有消除授權盤點、漏洞通報、版本更新與緊急重發的責任。第三項則是人力:核心開發者不必人人精通 Rust,但若關鍵模組只有少數人能審查,記憶體安全收益可能換來維護瓶頸。

對台灣開發者與企業的意義

短期內,多數使用官方映像、雲端服務或 Linux 發行版 Python 的團隊無須改程式;真正的選擇權先落在發行商。使用 PyO3、Maturin 製作擴充模組的維護者,也不應把尚未公開的 CPython Rust API視為穩定介面。

對自行編譯 Python、維護離線環境、工控設備或多架構映像的台灣企業,影響會更早出現:建置流程可能需要新增 Rust 編譯器、快取與軟體材料清單,也要確認舊版 glibc、交叉編譯及內部弱點修補政策是否承受得住。作者觀點是:是否採用 Rust,不應由語言偏好決定,而應比較崩潰率、效能、可重現建置、平台覆蓋率與可持續維護人數。

後續觀察指標

  • 正式 PEP 是否提交、接受,以及「選用」轉為「必要」所需的明確門檻。
  • zlib Rust 與 C 後端在真實 wheel、不同 CPU及小檔案情境下的端到端數據。
  • CPython 所有分級平台能否建置、測試與除錯,而不只是編譯通過。
  • 外部 crate 的存放、稽核、CVE 修補及安全重發責任由誰承擔。
  • 是否有足夠核心開發者願意審查 Rust,以及新增複雜度有沒有造成可量測的效能退步。

因此,真正值得關注的不是 Rust 會不會「取代 C」,而是 CPython 能否建立一套可撤回、可量測、能被發行商接受的雙語言治理模式。zlib 只是第一個試題;答案要由數據、平台與維護能力共同決定。

[Tempest Rust Daily] 技術情報精華 (2026-10-05) – 深度完整版

本期焦點涵蓋 Rust 編譯器行為、跨語言整合、訊息系統、資料隔離與新興開發工具。以下整理值得關注的技術文章與專案。

derive 巨集經常隱含 inline

文章指出,Rust 透過 #[derive(...)] 自動實作 Debug、Display、Clone 等核心 trait 時,目前可能同時產生 #[inline]。這項容易被忽略的編譯器行為,有助於理解衍生實作的程式碼生成方式與最佳化特性。

原文:https://ift.tt/sPlBRGy

從一則訊息理解 RocketMQ Rust

文章沿著單一訊息的生命週期,檢視 RocketMQ Rust 的架構與部署方式:發送呼叫返回後由哪個程序接收、資料何時進入儲存層,以及回應遺失、消費者重新啟動或資料庫更新成功時,系統會如何處理。這種分析方式適合用來釐清訊息可靠性與服務邊界。

原文:https://ift.tt/TcXfF4i

Rust 搭配 PostgreSQL RLS 的多租戶隔離

作者分享一套由單一 Rust 執行檔與 PostgreSQL 16 組成的雙容器架構,不額外使用 Redis 或 Kafka。儀表板查詢透過 PostgreSQL Row-Level Security,並以 SET LOCAL app.current_org_id 指定組織範圍,目標是在共用資料庫中降低應用程式錯誤造成跨租戶資料外洩的風險。

原文:https://ift.tt/3aYLoIt

Rust 納入 CPython 的評估方向

David Hewitt 在 PyCon US 2025 初步探詢後,進一步向 Python 核心開發者討論 CPython 導入 Rust 的需求,並提出時程、階段與成功標準。另一篇報導則從 Python 安全開發者 Seth Larson 的觀察切入,呈現官方核心開發者社群如何評估這項嘗試。

相關文章:https://ift.tt/GV0Ax7z

延伸報導:https://ift.tt/5WSVlkz

Tarvos:以 Rust 為中介的 Python 原生編譯器

Tarvos 鎖定可靜態分析的 Python 子集,依序進行型別檢查、降階至中介表示、產生 Rust 程式碼,最後輸出不需 Python 執行環境的獨立原生執行檔。作者特別強調這是子集編譯器,而非 CPython 的完整替代方案,並徵求社群對測試方法的意見。

原文:https://ift.tt/7oVIjbt

從 Rust 呼叫 C++ 靜態方法

這則討論聚焦於如何在不修改既有函式庫的前提下,從 Rust 呼叫 C++ 類別的靜態方法。範例同時涉及原始指標、自訂回傳型別與 C++ ABI,是規劃 Rust/C++ FFI 邊界時常見且具代表性的整合情境。

原文:https://ift.tt/0KZBokM

Rust 1.99.0 與 C 風格可變參數函式

文章整理 Rust 1.99.0 對可變參數函式的支援、原始指標安全規則的明文化,以及與下一版本相關的文件調整。對需要銜接 C ABI 或處理底層介面的開發者而言,這些變更值得納入相容性與安全性評估。

原文:https://ift.tt/wNIZjU9

cliproxy-rs:統一多家 AI 帳號的本機端點

cliproxy-rs 是一項 Rust 專案,目標是把既有的 Claude、ChatGPT 與 Gemini 帳號整合到單一本機端點,讓不同程式開發工具能透過一致介面使用。對同時採用多個 AI 服務的工作流程而言,這類代理層可簡化工具端設定。

原文:https://ift.tt/N6jGiDx

Cranpose:以 Rust 實作 Jetpack Compose 概念

Cranpose 嘗試把 Android 開發者熟悉的 Jetpack Compose 經驗帶入 Rust 生態系。作者經過近一年的構想與開發後公開專案,希望蒐集社群回饋;其核心方向是探索宣告式 UI 模型如何在 Rust 中落地。

原文:https://ift.tt/KfT7u2v

從 JavaScript 開發者角度理解 Rust 所有權

文章以 Node.js 中物件傳遞、原地修改與資料複製等常見問題為起點,帶領 JavaScript 開發者理解 Rust 的所有權模型。透過熟悉的可變資料情境切入,有助於建立所有權、借用與資料生命週期的直覺。

原文:https://ift.tt/chWoF4d

低規格 VPS 上的八種後端技術比較

這項實驗在配備 1 顆共享 CPU 與 2GB 記憶體的平價 VPS 上,以相同負載測試 Node、Bun、Python/FastAPI、Go、Java/Spring Boot、C#、PHP/Laravel 與 Rust。雖然摘要未提供測試數據與方法細節,但其統一硬體與負載的設計,可作為討論不同後端技術資源需求的起點。

原文:https://ift.tt/jrlpOdi

[Tempest Rust Daily] 技術情報精華 (2026-09-30) – 深度完整版

本期整理 Rust 生態系的實務案例與技術動向,涵蓋桌面工具、Web 後端、資料庫套件、GPU 程式設計、GUI 框架,以及序列化與型別處理等主題。

用 Rust 統一控制多螢幕亮度

開發者以 Rust 打造 Windows 系統匣工具,讓使用者能從同一介面調整各顯示器的亮度。筆電螢幕透過 Windows 內建的 WMI 控制,外接螢幕則使用 DDC/CI,省去逐台操作實體按鍵的麻煩。[https://ift.tt/Mpa0AnO]

給 C#/.NET 開發者的 Rust 入門指南

這份非完整指南以 C# 與 .NET 開發者為主要讀者,對照兩邊能互相映射的概念與語法,也介紹 Rust 記憶體管理等差異較大的設計。適合已熟悉 .NET、希望建立 Rust 心智模型的工程師。[https://microsoft.github.io/rust-for-dotnet-devs/latest/]

在 Termux 上實作終端機抽籤程式

一位來自孟加拉、剛接觸 Rust 的開發者,在手機的 Termux 環境完成抽籤應用程式。程式可接收並儲存姓名、隨機抽出結果,也能刪除既有名單;作者公開作品,希望社群協助進行程式碼審查。[https://ift.tt/21vYaM4]

從資料結構著手降低 DNS 快取記憶體用量

文章探討 Cloudflare 工程師如何調整 Rust 資料結構,減少不必要的記憶體浪費並改善 DNS 快取效能。標題宣稱節省了 100 TB 記憶體,內容焦點則是小型程式碼與資料配置最佳化在大規模服務中的累積效益。[https://ift.tt/QcIkeKM]

以 Rust 重製 ONCE Campfire

此專案將原本的 Rails 應用程式移植至 Rust,並以單一執行檔提供服務。開發目標包括維持畫面與通訊協定的一致性,以及直接沿用既有的 SQLite 資料庫和儲存目錄;作者宣稱完成相容性後,效能可達原版本的 19 至 44 倍。[https://ift.tt/wt1i8Hd]

用 Rust 改寫 FastAPI 限流瓶頸

作者表示 Python API 在每秒 10,000 次請求的負載下出現瓶頸,因此將限流器改以 Rust 實作。依文章標題所述,改寫後延遲降低 94%;案例重點在於辨識後端熱點,再針對關鍵路徑導入 Rust,而非全面重寫整套服務。[https://ift.tt/D8OMrqU]

Rust 擴充套件進入 PostgreSQL RPM 軟體庫

PostgreSQL RPM 軟體庫開始納入 Rust 相關套件,首批包含 pgrx 與 postgresql_anonymizer,並同步提供封裝規範。公告也提醒目前仍存在部分限制,對需要在 RPM 系統部署 PostgreSQL Rust 擴充功能的維運團隊而言,是值得關注的封裝進展。[https://postgr.es/p/9ww]

Rust Coreutils 0.12.0 聚焦 Ubuntu 相容性

Rust Coreutils 0.12.0 的開發重點是改善 Ubuntu 使用情境下的相容性。相關討論同時涉及專案承認曾複製 GNU GPL 程式碼的議題,使這次版本除了技術修正,也受到開源授權與程式碼來源管理方面的關注。[https://ift.tt/B5MiwuL]

探索 Arc 向下轉型與 Pin 的組合問題

作者在開發建置驅動程式時,遇到需要處理 Arc 向下轉型的特殊情境,並提出一套非典型解法。文章從實際問題出發,逐步說明 Arc、型別擦除、向下轉型與 Pin 之間的限制,適合想深入理解 Rust 型別與指標語意的讀者。[https://ift.tt/vodh2pF]

推動 Rust 原生 GPU 程式設計支援

rust-gpu 與 Rust CUDA 維護者 Christian Legnitto 持續探索以 Rust 開發 GPU 程式的可能性。現有專案已能讓開發者使用 Rust 撰寫部分 GPU 工作負載,但作者希望進一步改善工具鏈整合與原生支援,使 GPU 開發體驗更接近一般 Rust 專案。[https://ift.tt/PHsg3bc]

Git 用戶端從 Tauri/React 改用 Iced

一款以 Rust 開發的 Git 用戶端,將介面從 Tauri 搭配 React 改寫為 Iced。這次重構源於既有混合式架構的技術困擾,目標是統一技術堆疊、改善效能,並強化 Linux 支援;案例也呈現 Rust 原生 GUI 與 Web 前端方案之間的取捨。[https://ift.tt/m4rDbPE]

Deser 重新思考 Rust 序列化設計

Serde 長期是 Rust 生態系的重要序列化函式庫,但作者在實務使用中遇到若干限制,因此提出 Deser,嘗試重新思考序列化介面與架構。由於 Serde 已擁有龐大生態系,替代方案面臨的不只是 API 設計,也包含相容性與套件採用等挑戰。[https://ift.tt/8S2zJbN]

[Tempest Rust Daily] 技術情報精華 (2026-10-01) – 深度完整版

本期聚焦 Rust 生態系的供應鏈安全、編譯器演進、跨語言整合與多項實作案例,涵蓋網路服務、機器學習、嵌入式裝置、資料庫工具及影音應用。

arrayref 供應鏈攻擊:惡意 build.rs 在編譯期間執行酬載

文章指出,arrayref 0.3.10 加入名稱近似 proc-macro2 的 proc-macro1 相依套件,後者會透過建置腳本下載並啟動二進位檔。事件凸顯 Cargo 套件的 build.rs 能在編譯階段執行程式碼,也提醒團隊審查新增相依套件、鎖定版本及監控建置環境的重要性。

[https://ift.tt/rpoQAwG]

Rust for CPython 專案進度與可能的納入標準

David Hewitt 在 Python Language Summit 分享 Rust for CPython 的最新狀態、首個模組,以及未來可能採用的驗收標準。這項工作關注 Rust 與 CPython 核心開發的整合方式,對 Python 底層元件導入記憶體安全語言具有指標意義。

[https://ift.tt/AnyFK43]

Ulua:以純 Rust 實作 Luau、JIT 與 WebAssembly

Ulua 是 Luau 語言的開源純 Rust 實作,並提供 JIT 與 WebAssembly 支援。Luau 源自 Lua 5.1,加入漸進式型別等特性;專案同時提供程式碼儲存庫、線上 Playground 與 crates.io 套件,方便開發者測試與整合。

[https://ift.tt/dUIM4WQ]

Tako 以共通模型整合多種網路傳輸協定

Tako 是用於建構 Rust 網路服務的多傳輸協定框架,不只鎖定傳統 HTTP 應用,而是讓不同協定共用路由、中介軟體與可觀測性模型。對同時提供 Web API 與其他網路介面的服務而言,這種設計有助於減少各協定實作之間的重複工作。

[https://ift.tt/6y8EfK3]

RLX:Rust 多後端張量編譯器與分散式執行環境

RLX 試圖以統一架構處理張量圖編譯、核心運算執行與分散式執行環境。其研究動機是改善現有機器學習技術棧分散於不同語言與層級所造成的問題,讓後端行為、部署保證及效能降級策略更容易從端到端理解。

[https://ift.tt/3dJU4DC]

從單一檔案到 Workspace 的 Rust 專案結構

這篇文章討論 Rust 專案在不同成長階段適合採用的目錄與套件結構,核心觀點是不必過早加入架構複雜度。開發者可先從簡單配置起步,再隨程式規模、模組邊界及共用需求逐步拆分 crate,最終視需要轉為可擴充的 Cargo workspace。

[https://ift.tt/bI5tZoL]

以 Rust 裸機非同步技術驅動彩色電子紙

此實作使用 esp-hal、Embassy 與 epdsi,在 Seeed reTerminal E1002 上以裸機非同步 Rust 驅動 7.3 吋 Spectra 6 彩色電子紙,並涵蓋 microSD 等周邊。案例展示 Rust 嵌入式生態系如何組合硬體抽象層、非同步執行器與顯示器驅動程式。

[https://ift.tt/2apAjxy]

DuckPlus:專為 DuckDB 打造的原生 Rust IDE

DuckPlus 是以 Rust 開發的原生 DuckDB 用戶端,設計重點不是把 DuckDB 當成眾多資料庫驅動之一,而是直接支援 FROM-first 查詢、DESCRIBE、資料表函式、DuckDB 型別與管理函式等專屬能力。作者也表示,用戶端本身同樣採用 DuckDB。

[https://ift.tt/Jvj1tOn]

StreamNook 整合多平台直播並降低瀏覽器負擔

StreamNook 是以 Rust 建構的輕量直播用戶端,整合 Twitch、Kick、YouTube 與 TikTok LIVE。聊天、表情符號及輪詢等工作由 Rust 處理,並提供跨平台追蹤清單、開播通知及同時觀看多個直播等功能,目標是在遊戲期間減少瀏覽器對系統資源的影響。

[https://ift.tt/YQ7cmMU]

CapRust 釋出 Windows 原生影片編輯器 Alpha 0.6.0

CapRust 是使用 Rust 與 egui 開發的 Windows 原生影片編輯器,鎖定短影音與長影音內容製作,並納入 AI 相關工作流程。專案起源於作者使用 AI 影片生成模型時對既有工具操作方式的不適應,目前版本仍處於 Alpha 階段。

[https://ift.tt/Q7t89LS]

[Tempest Rust 深度解讀] 一個 build.rs 就能攻破供應鏈:arrayref 惡意版本如何滲入 Rust 編譯流程 (2026-10-01)

事件背景:惡意程式藏在「編譯」而非成品裡

2026 年 8 月 20 日,Rust 套件生態發生一起典型的供應鏈入侵:熱門小型套件 arrayref 的 0.3.10 版新增了對 proc-macro1 的直接依賴,而後者的建置腳本會下載並啟動外部程式。事件原始分析可見 https://dev.to/axrisi/rust-malware-in-arrayref-how-a-buildrs-ran-a-payload-at-compile-time-e7f。

Rust 安全回應團隊證實,arrayref 0.3.10 於 07:15 UTC 發布,08:41:40 被移除,存活約 86 分鐘;同一維護者帳號下的 internment 0.8.7 與 append-only-vec 0.1.9 也受到影響。官方表示不認為原作者具有惡意,較可能是電腦或帳號憑證遭入侵,並已鎖定帳號、刪除惡意套件及恢復先前被撤回的乾淨版本。這是官方已確認的事實,而不是對維護者動機的臆測。公告見 https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/。

攻擊鏈如何運作

第一層掩護是名稱與程式內容。proc-macro1 很像廣泛使用的 proc-macro2,發布帳號名稱也只與知名維護者 David Tolnay 的帳號相差一個字母。SafeDep 的樣本分析指出,其函式庫原始碼大致是可正常運作的 proc-macro2 複本,真正異常之處在 build.rs,以及新增的 Base64、TLS 與 HTTP 建置相依套件。換言之,單看「能否順利編譯」很難發現問題。技術拆解見 https://safedep.io/arrayref-proc-macro1-rust-build-time-malware/。

第二層是 Cargo 的正常設計。依 Cargo 官方文件,只要套件根目錄存在 build.rs,Cargo 就會先將它編譯成執行檔並執行,完成後才繼續建置套件;腳本原本用於編譯 C 函式庫、產生程式碼或偵測系統環境。官方甚至明載腳本可以執行「任意數量的工作」。文件見 https://doc.rust-lang.org/cargo/reference/build-scripts.html。

本案利用的正是這個信任邊界:arrayref 本身不必直接放入下載器,只要宣告一個非選用依賴,Cargo 就會處理該依賴及其建置腳本。SafeDep 分析顯示,Unix 版本會把下載內容寫入 /tmp/rust-setup、設定為可執行並啟動;Windows 則透過 PowerShell 與 VBScript 啟動。這些是樣本行為的分析結果,不等於每次下載套件都必然成功感染。

為何這起事件特別值得注意

攻擊者不只發布新版本,也撤回多個較新的乾淨版本。原始報導指出,Cargo 對遭撤回版本所顯示的更新提示,反而可能把使用者推向當時唯一未撤回的惡意版本。合理推論是:當攻擊者取得維護帳號後,版本管理、套件發布與警告訊號可能同時遭到操控;「看到 yank 就立即升級」因此不能再被視為無條件安全的操作。

更關鍵的是,攻擊發生在建置環境。開發者電腦與 CI runner 往往保存原始碼存取權、SSH 金鑰、套件發布權杖及雲端憑證。這些資產是否真的被竊取,官方公告沒有定論;但從權限模型推論,惡意腳本能接觸的範圍取決於執行 Cargo 的帳號擁有什麼,而不是最終程式被允許做什麼。

實際影響與不能混為一談的數字

RustSec 紀錄顯示,0.3.10 在下架前被下載 2,285 次,占同一時段 arrayref 全版本流量不到一成,原因是多數使用者仍被既有 lockfile 固定在舊版;受影響版本為 0.3.10,0.3.9 以下列為不受影響,且沒有「修補版」,因為處置方式是直接刪除惡意版本。資料見 https://github.com/rustsec/advisory-db/blob/main/crates/arrayref/RUSTSEC-2026-0260.md。

但「下載 2,285 次」不等於 2,285 台主機遭入侵:下載可能來自快取、鏡像或未完成的建置;反過來說,同一份快取也可能供多次建置使用。現有公開資料不足以給出實際受害主機數,也不足以完全確認第二階段惡意程式的所有能力。這是本案最容易被新聞標題省略的限制。

對台灣開發團隊的意義

這不是只有 Rust 維護者才需處理的問題。只要台灣團隊在後端、區塊鏈、桌面應用或基礎設施工具中使用 Cargo,風險就會落到開發機與 CI/CD。作者觀點是,防線不應只問「套件有沒有已知漏洞」,還要問「這次解析出的相依套件,會在編譯前執行什麼」。

  • 應用程式與服務應提交並審查 Cargo.lock,避免建置時無意間解析到剛發布的新版本。
  • 升級時檢查 lockfile 與 Cargo.toml 差異,特別留意新增的 build.rs、建置相依套件、網路或 TLS 函式庫。
  • CI 建置環境採最小權限、短效憑證與預設限制對外連線;機密發布工作不宜與一般相依套件建置共用同一個高權限 runner。
  • 依 Rust 官方清單檢查開發機及持久化 CI 快取。若找到相關套件,只能證明檔案曾被拉取;若確認建置曾執行,則應以可能失陷處理,保存紀錄、重建環境並輪替該帳號可讀取的憑證。

後續觀察指標

接下來值得觀察三件事:crates.io 是否為已刪除的惡意版本保留不可下載但可稽核的事件標記;Cargo 或周邊工具能否在執行建置腳本前,清楚揭露新增腳本與網路能力;企業端能否保存「當時解析到哪個版本、校驗值與 yank 狀態」的建置證據。

這起事件顯示,86 分鐘內下架套件可以縮小曝險,卻不能回答每個組織最重要的問題:當時究竟有什麼程式在誰的權限下執行。lockfile 已證明能降低自動升級造成的擴散;下一步則是把相依套件解析、建置腳本執行與憑證暴露範圍,一併納入可追溯的軟體供應鏈紀錄。

[Tempest Rust 深度解讀] OpenAI 用 Rust 重寫每秒 7,000 萬次請求的 Habitat:兩人加 AI 的系統工程實驗 (2026-09-26)

「OpenAI 用兩名工程師加 AI,把核心系統從 Python 改寫成 Rust,效能提升六倍」是個吸睛說法,但真正值得研究的,不只是程式語言之爭,而是 OpenAI 如何在產品高速成長時,先接受技術債、穩定介面,再於合適時機重寫執行層。這是一個關於架構時機、成本控制與 AI 輔助工程的案例。

事件背景:Habitat 並非 OpenAI 的全部核心系統

台灣媒體報導將 Habitat 描述為 OpenAI 的「核心線上儲存平台」,並指出 Rust 版本的 CPU 效率為 Python 版六倍、記憶體效率為十五倍。報導來源可見:https://www.techbang.com/posts/133128-openai-rewrites-python-core-in-rust-for-gpt-5-5。

OpenAI 第一方技術文章則提供了更精確的邊界:Habitat 是讓 ChatGPT、Codex、API 與內部服務存取線上資料的平台,負責路由、授權、加密、快取、請求整形與連線管理等工作;它不是模型訓練、推論或 OpenAI 所有後端系統的總稱。截至文章發布時,Habitat 每秒處理逾 7,000 萬次請求、管理逾 500 PB 資料,服務範圍接近 40 個地理區域。第一方資料:https://openai.com/index/scaling-storage-one-billion-users-part-one/。

真正的第一步不是 Rust,而是把函式庫變成服務

Habitat 最初於 2023 年推出,是嵌入 ChatGPT 主伺服器的 Python 函式庫,替產品團隊隱藏 Azure Cosmos DB、快取與其他儲存資源的複雜度。這種模式適合早期快速開發,卻會讓儲存邏輯跟著每個應用程式散布出去。

到了 2025 年中,修改路由或協定已經需要協調數十個服務重新部署;甚至有團隊因其他原因回復舊版本,重新帶回已修正的錯誤。OpenAI 因而先將 Habitat 抽離成集中式服務,使部署、監控、存取控制、稽核與資源限制可以在同一入口執行。

來源事實是 OpenAI 先完成服務化,之後才遷移 Rust。合理推論則是:先固定 API 與責任邊界,可降低重寫時必須同時改動產品端的範圍。換句話說,兩名工程師能推進改寫,未必只是 AI 寫程式變快,也與前一年已完成的架構解耦有關。

Python 為何撐得住,又為何最後不划算

Python 並沒有「無法做大型系統」。OpenAI 表示,Python 版 Habitat 高峰曾處理每秒逾 2,000 萬次請求。問題在於 Habitat 不只等待資料庫回應,也要做壓縮、加密、校驗、路由、健康檢查及流量複製;當 CPU 工作增加,asyncio 的協程即使具備 I/O 併發能力,也可能因事件迴圈排程延遲而拉高尾端延遲。

Python 官方文件也說明,一般 CPython 的 GIL 同一時間只允許一個執行緒執行 Python 位元組碼;I/O 或部分原生擴充套件可釋放 GIL,而 Python 3.13 起亦提供可停用 GIL 的自由執行緒版本,因此不能把所有問題簡化成「Python 一定不能平行」。官方說明:https://docs.python.org/3/glossary.html#term-global-interpreter-lock。

OpenAI 當時的解法是限制每個行程的併發量、增加大量工作行程,並監測事件迴圈延遲。但行程變多又會增加記憶體與下游連線數。團隊還發現 aiohttp 預設的 LIFO 連線重用,在尖峰後會把新請求重新送往較慢的伺服器,形成自我強化的過載;改成 FIFO 後才切斷這個回饋循環。這說明瓶頸來自語言執行模型、連線池、排程與流量形狀的組合,而非單一語法速度。

六倍效能代表什麼,又不代表什麼

OpenAI 表示,2026 年第二季由兩名工程師搭配 Codex 與 GPT-5.5 完成 Rust 重寫;發布技術文章時,Rust 版本已承接 95% 生產請求,CPU 效率為 Python 版六倍、記憶體效率為十五倍,平均與尾端延遲也顯著降低。因此「全面完成切換」仍稍嫌超前:第一方原文是計畫在接下來數週淘汰剩餘 Python 服務。

這些數字也是 OpenAI 的內部量測,不是公開可重現的獨立基準。原文尚未揭露硬體、請求組成、比較期間、編譯設定及效率計算公式,也未拆分效能究竟有多少來自 Rust、資料結構調整或重寫時順便完成的架構最佳化。六倍 CPU 效率更不等於總帳單降為六分之一,因為 Habitat 還依賴 Envoy、網路、Cosmos DB、快取及跨區基礎設施。

Rust 的所有權規則由編譯器檢查記憶體管理,且不需為此加入執行期垃圾回收;這有利於控制資源與延遲,但也提高型別、生命週期及非同步程式設計的學習成本。Rust 官方說明:https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html。

AI 在這次重寫中能證明到哪裡

可確認的事實只有 OpenAI 宣稱兩名工程師運用 Codex 與 GPT-5.5 完成重寫;原文沒有公布 AI 生成的程式碼比例、人工審查工時、缺陷率,也沒有說明測試、部署、資安與基礎設施團隊是否另有投入。因此不能直接推導出「任何兩人團隊都能靠 AI 重寫關鍵系統」。

作者觀點是,AI 最可能放大的不是憑空設計分散式系統的能力,而是既有介面下的搬遷效率:轉譯重複邏輯、補齊測試、處理型別錯誤及協助比對新舊實作。真正高風險的部分仍是定義相容性、驗證資料語意、安排漸進導流與決定何時回復。

對台灣團隊的意義

台灣的電商、金融、遊戲與 SaaS 團隊不應把此案解讀成「Python 都該換 Rust」。更實用的判斷順序是:

  • 瓶頸是否已由量測確認在應用程式 CPU、記憶體或尾端延遲,而非資料庫與網路?
  • 核心 API、資料語意與錯誤行為是否足夠穩定,可以讓新舊版本並行驗證?
  • 長期節省的運算成本與容量風險,是否高於招募、培訓、維運及重寫成本?
  • 是否能先以受限介面、查詢隔離與集中治理,解決比語言效能更根本的問題?

Habitat 最值得借鏡的設計,其實是刻意「少做」:只提供成本可預測的 NoSQL 操作,不讓線上路徑任意執行跨表關聯或無界限掃描;複雜搜尋與分析則透過 CDC 分流至 Rockset。這種把昂貴操作從交易路徑隔離的做法,往往比直接更換語言更早產生效益。

後續觀察指標

接下來應觀察 OpenAI 是否如期將剩餘 5% 流量遷出 Python、是否公開六倍與十五倍數字的測試方法,以及承諾中的 Habitat 第二篇技術文章能否說明跨區、多租戶與資料庫層的成本。若未來能看到故障率、p99/p999 延遲、每百萬次請求成本及 AI 產碼的驗證流程,這個案例才足以從亮眼成果,進一步成為其他團隊可以評估與複製的工程方法。