大家好，這裡是 Tempest Rust Daily 2026-05-01 技術情報精華。今天的選題涵蓋 pgrust 把 PostgreSQL 改寫進度推到 67%、LogBlast 在 Rust 上挑戰 grep+awk、Rust Stub Kernel 給作業系統入門者一個起點、This Week in Rust 第 649 期、Rust 1.85 vs Python 3.13 的 startup 工作流爭論、UDP Telemetry Firehose 在 bare metal 上贏雲端 10 倍、Astral 用 Rust 重寫 Python 工具鏈、自製 macros.rs 小工具集、把 AI agent 用 Rust 重寫的 RustyClaw、從 32-bit Protected Mode 跳到 64-bit Long Mode 的 OS-Dev 實作，以及 Rust 官方 GSoC 2026 入選專案揭曉，幫台灣工程師快速掃過這一輪 Rust 社群動態。
pgrust 進度更新：PostgreSQL 相容度衝到 67%，速度還在加快
pgrust 是把 PostgreSQL 用 Rust 從零重寫的個人專案，原始 pgrust 介紹文發布後一週，作者再次更新進度：目前 Postgres 相容度已經來到 67%，而且開發速度持續加快。作者強調這個專案的終極目標不是另起一個資料庫，而是要做出一個「在 Rust 工程文化下更安全工作」的版本，作為改進 Postgres 本身的實驗載體。
對台灣資料庫與後端工程團隊而言，這類專案短期內當然不會取代 production PostgreSQL，但「相容度 67% 而且加速中」這個訊號值得記下：它代表 Rust 在大型 SQL 引擎重寫上不只是 PoC，已經開始穩定迭代到具備實驗價值的狀態。如果你的團隊有興趣追蹤 Postgres 內部設計或想藉由閱讀 Rust 版了解儲存引擎、planner、parser，pgrust 是非常好的閱讀標的。原文連結：[https://ift.tt/wer8p3h]
LogBlast：用 Rust 寫的高效能 log 分析器，告別深夜 grep + awk 拼裝
作者描述了大家都熟悉的場景：凌晨兩點除錯 production，Nginx access log 8GB，grep / awk / cut 拼一拼跑好幾分鐘，最後拿到的還是雜亂不完整的洞察。受夠之後他用 Rust 打造了 LogBlast，定位是「現代化、高效能」的 log 分析器，目標是取代手寫一次性 shell pipeline 的痛苦。
對台灣 SRE 與平台工程團隊來說，這類工具的價值是把「臨時拼接 shell 指令」這個操作標準化成可重複、可帶速度的工具。重點不在語言選擇，而是工程師願不願意把常用 log 操作收斂成 binary，避免每次事故都重新發明 awk 一次。即使最終不採用 LogBlast，閱讀其實作仍是個練習：怎麼用 Rust 處理 GB 等級檔案、怎麼設計 zero-allocation 的 line scanner、怎麼把 column 抽取做得乾淨。原文連結：[https://ift.tt/YwLo0V5]
Rust-Kernel-Stub：給想自幹 OS 的人一個 Rust 起手範本
GitHub 上的 t4ce/Rust-Kernel-Stub 是作者放出來給社群當「Rust OS 開發起點」的專案。它不是完整作業系統，而是把 bare metal 開發初期最容易卡住的環境設定、build 設定、minimal kernel 進入點等樣板程式整理好，讓你可以聚焦在自己想做的部分。
對台灣有興趣鑽研 OS 內核、bootloader、嵌入式 Rust 的工程師而言，這類 stub 專案非常適合用來剝離雜訊：你不需要先理解整個 linker script、target.json、core 與 alloc 的 no_std 配置，就可以直接在乾淨的骨架上開始實作排程器、記憶體管理、簡單 syscall。對教學情境（學期專題、讀書會、技術寫作）也是一個方便援用的範本。原文連結：[https://ift.tt/OHNmYTQ]
This Week in Rust 第 649 期：每週社群動態的固定追蹤點
This Week in Rust 是 Rust 官方社群每週發行的進度摘要，這週是第 649 期，內容慣例涵蓋 Rust 語言更新、值得關注的 crate、活動、求才訊息、社群文章與 RFC 討論等。對沒有時間每天滾 r/rust 與 internals.rust-lang.org 的工程師來說，這份週刊是「以最低成本掌握 Rust 生態節奏」的最佳單點訂閱。
建議台灣 Rust 工程團隊把 This Week in Rust 列入每週固定閱讀清單，並挑兩到三則跟自己 stack 最相關的條目排進內部技術分享。長期累積下來會比看單篇 viral 文章更能感受 Rust 真實的進展節奏，例如哪些 crate 正在快速迭代、哪些 RFC 進入 stabilization 流程、哪些 release note 含有可能影響你 build pipeline 的變更。原文連結：[https://ift.tt/5i1I2oX]
「2026 該選 Rust 1.85 還是 Python 3.13？」一場關於 startup 開發速度的爭論
作者拋出一個挑釁性的論點：在 2026 年，典型 4 人 startup 工程團隊一季要花 1,200 小時以上跟 Rust 1.85 的 borrow checker 與 build time 搏鬥，而 Python 3.13 的 JIT 加上 zero-boilerplate 的 async 工具鏈，能在 92% SaaS 場景帶來 3 倍 feature velocity。文章因此主張多數 startup 應該跳過 Rust，回到 Python。
這篇明顯偏 opinion piece，但對台灣早期團隊技術選型仍有討論價值：Rust 帶來的不是「更快寫完 feature」，而是「更慢寫完但更敢部署」。對 prototype 階段、需求高度漂移的產品，作者的批評不無道理；但若團隊鎖定的是高吞吐 backend、infra、嵌入式或關鍵路徑的 hot loop，Python 的 velocity 優勢就會被 GC 與型別維運成本稀釋。建議當作技術選型討論的反方素材，而不是行動指引。原文連結：[https://ift.tt/iqftlLZ]
UDP Telemetry Firehose：Rust + bare metal 把雲端方案打掉 10 倍
作者分享了一個自己親手做出、連自己都覺得驚訝的成果：用 Rust 在 bare metal 上做的 UDP Telemetry Firehose，效能比同等雲端方案高出 10 倍。重點不在追求極致 benchmark，而是把資料平面從 managed service 拉回到「自己挑網卡、自己挑 kernel bypass 路徑」之後，成本與延遲都出現實質改善。
對台灣金融、廣告、遊戲 backend、車聯網等有 high-throughput UDP 採集需求的團隊而言，這類個案有兩個值得吸收的觀念：第一，Rust 在資料平面的價值是「在不犧牲記憶體安全的前提下，可以摸到網卡與 NUMA 拓樸」；第二，雲端服務在某些工作負載上會變成 cost premium 的來源，當量級夠大、流量曲線夠穩定時，自建反而更划算。即便不打算馬上自建，閱讀此類案例可以校準對「雲端 vs 自建」效能差距的直覺。原文連結：[https://ift.tt/4QJZnSO]
uv、Ruff、ty：Astral 用 Rust 重寫的 Python 工具鏈正在改寫整個生態
這篇文章直接點出近年 Python 生態最值得記下的事實：Python 工具鏈長年支離破碎且緩慢，這場革命不是來自 Python 社群本身，而是來自 Rust——Astral 用 Rust 寫的 uv（套件管理）、Ruff（linter/formatter）與 ty（type checker），合計取代了過去半打工具，速度普遍比舊有方案快 10 倍到 100 倍。
對台灣同時維護 Python 與 Rust 專案的團隊（這在 AI、資料、後端基礎設施很常見）來說，這是一個典型「跨語言基礎設施」案例：你不必把產品改寫成 Rust，也能享受 Rust 帶來的工程效率紅利。實務上建議至少把 Ruff 與 uv 放進 CI 與本地開發流程，編輯器整合也已經成熟；ty 還在迭代，但值得追蹤是否能挑戰 mypy 與 pyright 的位置。從工程選型角度，這也提示一件事：寫 CLI 工具與 dev tooling 時，Rust 的啟動時間與 binary 體積是真實的競爭優勢。原文連結：[https://ift.tt/kSFCWsK]
My Tiny Rust Utils Part 1：把日常 Rust 小痛點收斂成 macros.rs
作者沒有自詡「我做了革命性的東西」，而是很誠實地說：他在做小型 Rust 專案時不斷遇到一些不戲劇但煩人的小摩擦，例如剛起步時 logging 的設定、樣板重複等等，於是慢慢累積出一個自己的 utils 資料夾，這篇是 macros.rs 的整理。
對台灣個人開發者與小型團隊而言，這篇文章的真正價值不在於那幾個 macro 本身，而在於它示範了一個健康的工作習慣：與其每次新專案都重新對抗一樣的摩擦，不如把它收斂成可重用的模組（甚至發成 crate）。在 Rust 生態中，「自有 utils crate」往往是團隊工程文化的訊號——你願不願意花時間把痛點變成資產。如果你還沒有自己的 dev utils，這篇可以當作起點：先從 macro 著手，因為這部分通常不依賴外部相依、最容易共用。原文連結：[https://ift.tt/3CImgfL]
RustyClaw：把 AI agent 用 Rust 重寫，因為「梗就是這樣」
RustyClaw 是作者把現有 AI agent 用 Rust 重寫的紀錄，行文走比較幽默自嘲的路線。這篇不是 framework 發表，而是「我把這件事做了一遍，順便整理為什麼選 Rust 以及踩到什麼坑」的開發日誌型文章，對 LLM agent 工程實作有興趣的讀者可以當作個案參考。
對台灣正在嘗試把 LLM agent 從 Python 遷移到更易部署語言的團隊而言，這類文章可以幫你預估「重寫成本 vs 收益」：Rust 能帶來更小的 binary、更可預測的啟動時間、更乾淨的 async 整合，但也會多吃 prompt engineering 之外的型別設計與 trait 抽象成本。建議搭配 This Week in Rust 中的 LLM/agent crate 動態一起看，避免重新造輪子。原文連結：[https://ift.tt/csrqfJG]
Beyond the Bootloader：在 Rust OS-Dev 裡完成 32-bit 到 64-bit 的躍遷
這篇講的是 Rust OS-Dev 一個很經典的中段：當 GRUB 透過 Multiboot2 把控制權交給你的 kernel entry point 時，CPU 還在 32-bit Protected Mode、interrupt 大概是關的、A20 line 已啟、segment register 設好了 flat 4 GiB descriptor。文章帶你一步一步把這個「還活在 1990 年代」的環境推進到 64-bit Long Mode。
對台灣有興趣寫 toy OS、研究 hypervisor、寫 firmware 的工程師而言，這是少數把 Rust + Multiboot2 + Long Mode 切換寫得清楚的文章。重點不只是 mode switch 的程式碼，更是「為什麼要設這些 segment register、為什麼 paging 一定要先建好、為什麼 Rust 這時還用不了完整的 std」這層工程脈絡。讀完之後，你對 Rust 在 no_std 環境下的限制會有更具體的體感。原文連結：[https://ift.tt/dITWgHs]
Rust 官方公告：Google Summer of Code 2026 入選專案揭曉
Rust Project 官方部落格宣布 GSoC 2026 入選專案名單。GSoC 是 Google 主辦的全球開源實習計畫，目的是把新貢獻者帶進開源專案，Rust Project 連續多年參與，這一輪的入選專案代表未來幾個月會有 mentor 帶領的明確工作項目落地。
對台灣學生與想要開始貢獻 Rust 上游的工程師來說，GSoC 入選名單有兩個用途：一是看「目前 Rust 工具鏈與生態被認為最值得補強的方向」，這通常會反映後續半年到一年的迭代重點；二是把這些專案當成自己 side project 的選題地圖，即使沒有申請上 GSoC，沿著相同題目自主貢獻 PR，也是進入 rust-lang 組織的有效路徑。建議搭配 rust-lang/rust 的 issue tracker 一起看，比較容易找到對應的 mentor。原文連結：[https://ift.tt/4ez0ypL]
以上就是今天 11 則 Rust 技術情報。整體看下來，本期的主旋律可以分成三股：一是「Rust 在大型基礎設施重寫」（pgrust、Rust-Kernel-Stub、OS-Dev 的 64-bit 跳躍）持續累積實作；二是「Rust 對其他生態反向輸出工具」（uv/Ruff/ty 改寫 Python 工具鏈、LogBlast 取代 shell pipeline）；三是「在生產與 startup 場景的實戰權衡」（UDP Telemetry Firehose、Rust 1.85 vs Python 3.13、RustyClaw）。This Week in Rust 與 GSoC 入選名單則是兩個固定可以追蹤社群節奏的訊號源。Tempest Rust Daily 我們明天見。