Gossamer：融合 Rust 語法與 Go 並行模型的新系統語言
gossamer-lang.org · 2026-06-27 · v0.19.1（pre-1.0）
Gossamer 是一門以 Rust 語法為基礎、同時內建 Go 風格協程（goroutine）的系統程式語言，目前版本為 v0.19.1，處於 pre-1.0 穩定開發階段。它的核心目標是：讓開發者得到 Rust 的靜態型別安全與零暫停記憶體管理，同時徹底免除借用檢查器（borrow checker）的心智負擔，並從 Go 引入 M:N 協程排程器，避免 async/await 帶來的「函式著色問題」（function colouring）。
背景
Rust 在安全性與效能上首屈一指，但其所有權與生命週期系統對於初學者甚至中階開發者而言學習曲線陡峭。Go 雖以協程與通道（channel）大幅降低並行程式設計門檻，卻採用動態型別推斷與隱式介面，並依賴有停頓的垃圾回收（GC）。Gossamer 試圖在這兩條路之間開闢第三條：靜態型別加上無借用規則的自動記憶體管理，以及原生支援的協程並行。
語言設計靈感來自多個生態系，包含 Rust、Go、Kotlin 及 F#，並提供針對這些語言背景開發者的遷移指南（Migration Guide）。程式碼以 Apache-2.0 授權釋出，可透過 WebAssembly 編譯的 VM 即時執行，或透過 LLVM 後端編譯為無外部依賴的單一原生二進位檔。
核心改動
Gossamer 的並行模型以 go 表達式啟動協程，並搭配有型別的通道（typed channels）傳遞訊息。M:N 排程器確保阻塞式呼叫（例如 I/O）只會暫停該協程，不會卡住底層執行緒，因此不需要像 Rust async 那樣區分「同步函式」與「非同步函式」。以下為概念性範例：
// 啟動協程並透過通道回傳結果
let ch = chan();
go {
ch.send(compute_heavy());
};
let result = ch.recv();
記憶體管理採用「確定性參考計數（deterministic reference counting）」搭配 arena { } 區塊。arena 區塊內的所有物件在區塊結束時批次釋放，避免逐一遞減計數的成本，同時完全消除 GC 停頓。這與 Rust 的 bumpalo arena 分配器理念相似，但語法層面更為原生。
型別系統完整支援泛型（generics）、trait bounds、窮盡性模式比對（exhaustive pattern matching），以及 Option<T> 與 Result<T, E>。前向管線運算子 |> 鼓勵以函數式風格組合資料轉換，且頂層語句自動成為 main() 函式本體，無需樣板程式碼即可快速撰寫腳本。
影響範圍
Gossamer 目前仍處於 pre-1.0 狀態，尚無預建二進位檔，安裝需從原始碼編譯。官方計畫在 1.0.0 里程碑時提供預建版本。開發者比較此語言與主流選項時，可參考下表：
| 特性 | Rust | Go | Gossamer |
|---|---|---|---|
| 記憶體管理 | 所有權 / 借用 | GC（有停頓） | 參考計數 + arena（無停頓） |
| 並行模型 | async/await（函式著色） | goroutine + channel | goroutine + typed channel |
| 型別系統 | 靜態、強型別 | 靜態、部分隱式介面 | 靜態、trait-based |
| 學習曲線 | 陡（生命週期） | 平緩 | 中等（無借用規則） |
| 執行模式 | 原生二進位 | 原生二進位 | VM 腳本 / LLVM 原生二進位 |
對於需要在 Rust 安全性與 Go 開發速度之間取得平衡的後端工程師而言，Gossamer 提供了值得觀察的新方向。其最大潛在受眾是熟悉 Rust 語法、卻苦於借用規則的開發者，以及需要高並行但不滿意 Go GC 停頓特性的場景。語言表面已相對穩定，但 pre-1.0 的定位意味著 API 仍可能發生破壞性變更。
原始來源：gossamer-lang.org
Python 無 GIL 的過去、現在與未來：自由執行緒建置的現況剖析
LWN.net · 2026-06-26 · Python 3.13 / 3.14 / PEP 703
LWN.net 於 2026 年 6 月 26 日發表深度分析，梳理 Python 自由執行緒（free-threaded）建置的演進歷程：從 Python 3.13（2024 年 10 月）的實驗性支援，到 Python 3.14（2025 年 10 月）正式脫離實驗標籤，再展望 3.15 的統一 ABI。這是 PEP 703（由 Sam Gross 撰寫，2023 年 10 月獲 Steering Council 接受）落地後最完整的階段性總結。文章也預測，自由執行緒將在 Python 3.16（2027 年）至 3.20（2031 年）之間成為預設建置，而 GIL 的完全移除則預計再晚一個世代。
背景
CPython 的全域解釋器鎖（Global Interpreter Lock，GIL）自 1990 年代初期即存在，其設計目的是簡化 C 擴充模組的執行緒安全性。GIL 使得多執行緒程式在 CPU 密集型任務上無法真正平行執行，即便執行在多核心機器上，同一時間只有一條執行緒可以持有 GIL 並執行 Python bytecode。多年來多次嘗試移除 GIL 均因相容性問題而受阻，直到 Sam Gross 的 nogil 分支提出了一套系統性方案，最終形成 PEP 703。
Python Steering Council 以「漸進式推出、儘量不破壞現有生態」為原則接受了該提案，並將 --disable-gil 建置旗標引入 CPython，使兩種建置可以並存。自由執行緒這個術語由 Steering Council 欽定採用，以避免「No-GIL Python」或「nogil」等非正式名稱造成的品牌混亂。
規格細節
PEP 703 的核心技術方案包含四個主要機制：
- 偏向參考計數（Biased reference counting）：每個物件追蹤一個「擁有者執行緒」，該執行緒的計數操作為非原子（快速路徑），其他執行緒則使用原子操作。
- 延遲參考計數（Deferred reference counting）：將多次計數修改批次累積到垃圾回收週期一併處理，降低原子操作頻率。
- 靜止狀態回收（Quiescent-state-based reclamation）：確保記憶體延遲釋放，防止執行緒間競爭造成 use-after-free。
- 無鎖資料結構搭配 critical section：列表（list）與字典（dict）使用物件層級的細粒度鎖，而非全域鎖，且設計為無死鎖。
效能數字在版本間的改善幅度顯著。Python 3.13 的自由執行緒建置單執行緒效能損耗高達 20–40%，原因是許多路徑尚未最佳化；到了 Python 3.14，同等工作負載的單執行緒損耗已降至 0–10%（視硬體與編譯器而定）。目前 PyPI 前 360 大有二進位 wheel 的套件中，超過 50% 已支援自由執行緒建置，Meta 與 Quansight 是主要貢獻來源。
| Python 版本 | 發佈日期 | 自由執行緒狀態 | 單執行緒損耗 |
|---|---|---|---|
3.13 | 2024-10 | 實驗性（experimental） | 20–40% |
3.14 | 2025-10 | 正式支援（supported） | 0–10% |
3.15 | 2026-10（預計） | 統一穩定 ABI | 待測 |
3.16–3.20 | 2027–2031（預測） | 預設建置（預測） | — |
影響範圍
Python 3.15 計畫引入一個統一的穩定 ABI，讓 C 擴充模組的開發者只需編譯一次，即可同時相容 GIL 與自由執行緒兩種建置，大幅降低生態系碎片化的風險。這對於依賴 C 擴充的數值運算（NumPy、SciPy）及機器學習函式庫（PyTorch）而言是關鍵里程碑。對後端服務而言，自由執行緒最直接的受益場景是 CPU 密集型的多執行緒工作負載，例如 AI 推論服務、影像處理管線，以及不想引入多進程（multiprocessing）複雜度的高並行 API 伺服器。
值得注意的是，自由執行緒建置目前仍需透過 python3.14t（帶 t 後綴）或特定的 pyenv/conda 版本安裝，尚未成為 python3 的預設行為。現有的執行緒安全假設若依賴 GIL 作為隱式鎖，在遷移至自由執行緒建置後可能出現競爭條件（race condition），需要重新審視。
原始來源：LWN.net — Free-threaded Python: past, present, and future · PEP 703
Tropius：用 Rust 打造的 AI 文體辨識 CLI 工具
tangled.org / desertthunder.dev · 2026-06-26
Tropius 是一款以 Rust 撰寫的命令列工具，專門用於偵測文本中常見的 AI 生成語言模式（trope），在近期提交中新增了粗體條列項目偵測與嚴重程度標示功能。工具靈感來自 BlueSky 上一場關於如何識別「Claude 風格」文字的討論，並以 Tropes.fyi 的模式字典為基礎，以 Unlicense 授權釋出，可自由使用與修改。
原本的問題
大型語言模型（LLM）生成的文字往往帶有可辨識的語言慣例：過度使用 em dash 分隔從句、「短促有力卻矯飾浮誇」的散文節奏、結構性的「不只是 X，更是 Y」句型（所謂的「Claudeisms」），以及 Markdown 格式中以粗體開頭的條列項目。這些模式在人工審閱大量 AI 生成文件時難以系統性偵測，尤其是混合了人類改寫的段落時。Tropius 試圖提供一個可整合進 CI 管線或文字工具鏈的自動化偵測層。
採用的方法
Tropius 的偵測管線分為四個層次：
- Aho-Corasick 多模式字串比對：依據 TOML 格式的 trope 字典，對輸入文字進行字面短語掃描，時間複雜度與模式數量無關。
- 結構分析器（structural analyzer）：檢查句子與段落的組成比例，偵測過於一致的長度分布或重複的開頭詞。
- 重複偵測器（repetition detector）：識別隱喻語言的高密度使用與內容重複。
- 字元類別偵測器：標記 Unicode 裝飾字元（如全形引號、特殊破折號）及 Markdown 格式慣用模式（如
**粗體**開頭的條列項目）。
CLI 使用方式極為簡潔，透過標準輸入（stdin）傳入文字即可：
# 最基本的使用方式
printf 'Certainly! Here is a comprehensive guide...' | cargo run -q -p tropius-cli
# 搭配 lectito 從 URL 擷取文章內容後分析
lectito fetch https://example.com/article | tropius
CLI 的退出碼設計為可直接整合進腳本或 CI 管線：0 代表未偵測到 trope，1 代表發現可疑模式，2 代表設定檔錯誤。工具透過 NO_COLOR 環境變數支援無色彩輸出，適合機器解析。
實際效果
根據最近的提交記錄（距今約一天），Tropius 新增了對 Markdown 粗體條列項目的偵測，以及輸出中的嚴重程度指標（severity indicator），使得偵測結果更易於分層處理——例如將「低嚴重性」視為警告，「高嚴重性」視為阻斷錯誤。TOML 格式的 trope 字典意味著使用者可以自行新增或調整偵測規則，不需要重新編譯主程式。
Tropius 的定位是輕量的靜態分析工具，而非語義理解模型，因此存在固有的誤判率（false positive）。對於混合了人類撰寫內容的文件，逐段管線化處理可以提升精準度。對於需要在內容發布流程中加入 AI 文體稽核的後端服務，Tropius 提供了一個無需外部 API 呼叫、可離線運行的本地化解決方案。工具以 Unlicense 釋出，可直接嵌入商業工具鏈而無授權限制。