Nanobrew：與 brew 相容的最快 macOS 套件管理器

背景

Nanobrew 是一款使用 Zig 語言編寫的 macOS 套件管理器，主打極致的執行速度，聲稱比傳統的 Homebrew 快上數千倍。它透過原生 HTTP 客戶端、並行處理機制以及 macOS 特有的 APFS clonefile 技術，試圖解決 Homebrew 長期以來因 Ruby 運行環境與複雜依賴檢查所導致的延遲問題。

社群觀點

針對 Nanobrew 的出現，Hacker News 社群展開了關於「速度與相容性」的激烈辯論。支持者認為 Homebrew 的預設行為極其煩人，特別是每次安裝套件前強制執行的自動更新，往往讓原本簡單的任務變成數分鐘的等待。對於使用 Nix-Darwin 或自動化腳本的使用者來說，Homebrew 在處理不變動的設定檔時反應過於遲緩，這使得像 Nanobrew 這樣追求極速的替代方案顯得極具吸引力。部分開發者將此趨勢類比為軟體界的「Bun 化」，即利用底層語言重寫既有工具以獲取效能突破，認為這種競爭能倒逼主流工具進步。

然而，質疑聲浪主要集中在「相容性」的定義上。Homebrew 的核心維護者 Mike McQuaid 親自參與討論，指出 Nanobrew 若不執行 Ruby 程式碼，就無法達成真正的完全相容，因為 Homebrew 的許多功能與 Brewfile 本質上都是 Ruby 領域特定語言。他強調 Nanobrew 實際上是「隱形地」依賴 Homebrew 龐大的基礎設施、CDN 與維護人力，卻只做了一個輕量的前端。此外，有使用者實測發現 Nanobrew 目前尚無法支援 Cask 等重要功能，這讓其宣稱的相容性大打折扣。

另一派觀點則討論到工具的必要性。部分資深用戶認為，對於大多數人而言，套件管理並非頻繁操作，為了節省幾秒鐘而放棄穩定且生態完整的官方工具並不划算。但也有反對者反駁，糟糕的預設效能本身就是放棄軟體的正當理由。有趣的是，這場討論也引出了對 Homebrew 官方動向的關注，維護者透露官方正在開發以 Rust 編寫的新版前端，旨在保留完整相容性的同時提升效能，這或許才是社群最終期待的終極解決方案。

最後，部分用戶提到了對舊硬體支援的遺憾。隨著 Homebrew 逐漸放棄對舊版 macOS 的支援，一些仍在使用高效能舊款 Mac 的開發者感到被拋棄，雖然 Nanobrew 專注於現代 macOS 特性，但這也反映出社群對於更輕量、更具包容性的套件管理工具仍有未被滿足的需求。

延伸閱讀

• Homebrew Rust Frontend: Homebrew 官方正在開發中的 Rust 版本前端，旨在提升效能並保持完全相容。
• Zerobrew: 另一個同樣以提升 Homebrew 速度為目標的替代專案，且具備 Linux 相容性。
• MacPorts: 對於不滿意 Homebrew 支援策略或速度的另一種老牌替代方案。