2026-08-23 — LLVM 23 編譯期優化、Rust GUI 生態調查與 Gleam 語言設計巡禮

LLVM 23 大砍編譯時間：雜湊表、除錯資訊到預編譯標頭全面重構

Alexis Engelke 個人部落格 · 2026-08-22

LLVM 23 在官方 compile-time tracker 的 stage2-O3 組態下，整體編譯時間較前一版下降 6.75%，其中 sqlite3 amalgamation 的建置時間更減少了 10.53%。這些改動主要由 Alexis Engelke、Cullen Rhodes 與 Fangrui Song 陸續提交，累積整理成一篇文章，發表於 2026-08-22。作者強調這不是單一大改動，而是數十個 1% 以下的小優化疊加而成。

核心改動

最大宗的改動集中在底層資料結構。雜湊容器 DenseMap 等從 quadratic probing 改成 linear probing，去除 tombstone key 後帶來 -1.27%（DenseMap）、-0.24%（SmallPtrSet）、-0.10%（StringMap）的提升；雜湊函式也從 CityHash 換成 xxh3，再省下 -0.18%。SmallVector 把可簡單複製型別的 grow path 搬到 out-of-line 並加上 tail-call，讓暫存器配置與 inline 更順暢，貢獻 -0.50%。

DominatorTree 改用 child-sibling 表示法並導入 bump allocator，累積約省下 0.6%
IR 的 successors 改寫成對 Use range 的 iterator，需將 BranchInst 拆成 UncondBr 與 CondBr 兩個 opcode，帶來 -0.21%
Metadata 儲存方式由 hash map 改成單一 vector，省下 -0.35%
DebugInfo 移除 TrackingMDNodeRef，改用裸 MDNode 指標，stage2-O3 省 -0.50%，debug build（stage2-O0-g）省 -1.15%

影響範圍

LLVM 23 也首次為五個高頻使用的標頭導入預編譯標頭（PCH）基礎設施，整體建置時間再降約 45%。

標頭	編譯時間變化
LLVM Support	-14.73%
LLVM Core	-12.70%
LLVM CodeGen	-6.33%
clangAST	-13.85%
clangCodeGen	-8.12%

前端（parsing／語意分析）佔整體編譯時間的比例，也從超過 80% 降到約 55%，代表後端與最佳化流程相對吃重的比例上升。

原始來源：Compile-Time Improvements in LLVM 23

把 46 套 Rust GUI 框架都刻一次 QR Code 產生器之後

wybxc 部落格 · 2026-08

部落格作者 wybxc 用同一個 QR code 產生器當測試案例，在 macOS（部分 Windows 限定框架改用虛擬機）上實際刻了 46 套 Rust GUI 框架，逐一檢查可用性、無障礙（screen reader）與輸入法組字（IME）支援，整理成一篇長文評測。評測項目涵蓋文字輸入、圖片繪製與狀態管理等常見 UI 需求。

核心發現

作者認為 Slint 與 egui 是目前唯二在無障礙與 IME 上都沒有明顯短板的框架，分別代表 retained-mode 與 immediate-mode 兩種陣營的成熟解法。Cushy、Freya、Floem、Iced、Relm4、Xilem 的 API 設計評價不差，但輸入法或無障礙支援仍不完整。

GPUI 沒有內建文字輸入元件，作者得自己寫近 780 行程式碼繞過，部分 IME 操作仍會當機
Maycoon 已停止維護，作者直言「Rust 目前並不適合拿來做 UI framework」
Azul 無法讀取系統字型，Pax 編譯失敗且兩年沒有更新
Vizia 因無障礙資訊過期，會讓螢幕報讀軟體當掉

對於想做跨平台 App 的情境，作者建議 Crux 搭配 SwiftUI，或 Rinf／Flutter Rust Bridge；偏 Web 路線則可考慮 Dioxus 或搭配 tauri-specta 的 Tauri。整篇評測的結論是 Rust GUI 生態仍未收斂出一個「無聊但可靠」的預設選擇，多數框架的 CJK 字型與無障礙支援仍要額外處理。

原始來源：A 2026 Survey of Rust GUI Libraries

Gleam 的簡潔哲學：沒有例外、沒有 null，也不需要多重函式簽名

Alejandro Baez 個人部落格 · 2026-08-18

開發者 Alejandro Baez 在 2026 年 8 月 18 日發表文章，整理執行在 BEAM（Erlang 虛擬機）上的靜態型別語言 Gleam 幾項值得注意的語言設計。文章指出 Gleam 刻意捨棄不少「常見」語法糖，改用少量正交機制達成同樣效果。

規格細節

Gleam 不支援在函式簽名上直接寫多重分支（function head pattern matching），所有分支都得寫進 case 表達式。Lobsters 討論串指出，這其實是遷就 BEAM 本身：Erlang 虛擬機底層並不支援多重函式頭，Elixir 等語言的編譯器最終也是把它們 desugar 成 case 表達式，Gleam 只是把這個事實攤開來寫。

case level {
  1 -> "low"
  2 | 3 -> "medium"
  _ -> "high"
}

todo as "尚未處理超過 3 的等級"

錯誤處理上，Gleam 完全沒有例外機制，一律透過 Option 與 Result 型別強迫呼叫端顯式處理；也沒有一般語言的 null，Nil 只指向自己，「不存在」的語意同樣要靠 Option 或 Result 表達。函式與型別上可加 @deprecated 標記提示過時用法，語意類似 GraphQL 的 deprecated 修飾。

討論串裡也有資深開發者表示，捨棄多重函式頭並不會太不習慣，反而比較想念 if 陳述式；也有人認為文章應該更明確跟 Elixir 對比，畢竟 @deprecated 這類特性 Elixir 本來就有。

原始來源：The cool things of Gleam

End of article