Rust 數值 crates 最缺的不是功能，而是維護者

Rust 的數值生態真正缺口不是新 crates，而是能長期維持正確性、相容性與回應速度的維護者。

Rust 不是缺數值套件，而是太多數值套件被當成興趣專案在經營，沒有人把它們當成必須長期維持的基礎設施。

第一個論點：數值庫最重要的是穩，不是多

數學不會因為版本號改變，好的數值庫也不該為了活躍度而頻繁翻新介面。像 num-complex、nalgebra 這類 crates 的價值，正在於使用者預期它們有穩定 API、可預測語意、少一點破壞性更新。對數值堆疊來說，少發版往往比多發版更有價值，因為每一次變動都可能牽動下游的型別推導、泛型邊界與精度行為。

這不是抽象道理，而是工程現實。以科學運算、機器學習或金融計算為例，一個看似無害的最佳化就可能改變浮點誤差分布，甚至讓依賴鏈上的測試一夜之間全壞。相較之下，持續修補 bug、補齊文件、維持相容性，才是真正把 crate 當成可依賴基礎設施在照顧。數值庫的成熟，常常體現在它不吵、不變、但一直可用。

第二個論點：issue 多，不等於 roadmap 活

很多人看到 GitHub 上堆著一長串 open issues，就直接判定這個專案失控了。但對數值 crate 來說，這個判斷太粗暴。問題數量高，可能只是因為它被用得廣、邊界情況多、而且維護者人數少。對 correctness 要求高的專案，本來就不適合用一般開源專案的「提交頻率」來衡量健康度。

更重要的是，數值庫的工作很多都不會留下顯眼痕跡。三個月內沒有大功能，不代表沒有人在做事；維護者可能正在處理 compiler 相容性、CI 失敗、精度回歸、錯誤報告重現，或是審查一個會影響整個依賴圖的 PR。以 nalgebra 這類成熟庫為例，真正有價值的工作往往是把行為守住，而不是把介面做大。慢審查很煩，但比錯誤算術便宜得多。

反方可能怎麼說

反方的說法其實很強：如果一個 repo 幾個月都沒人回應 issue，也不 review patch，那它就不算活躍。開源靠的是回應速度，社群不該把時間浪費在沒有維護能力的專案上。對新手來說，缺乏回饋的倉庫確實會讓人挫折，因為你很難判斷自己的貢獻是否會被接住。

這個批評也有道理，尤其當專案完全沒有 maintainer presence 時，稱它為「維護中」確實會誤導使用者。貢獻者需要回饋迴路，沒有回饋，善意也會卡死在 queue 裡。

但結論不該是「Rust 的數值 crates 不行」，而是「很多數值 crates 人手太少」。對這類專案，正確標準不是 issue 清得多快，而是維護者是否仍在修 bug、守相容性、控制精度風險。安靜但穩定的倉庫，通常比熱鬧但亂改的倉庫更值得信任。若你要投入貢獻，應該找有明確維護者、最近有修 bug 記錄、而且貢獻規則清楚的 crate，而不是追著最長的 issue list 跑。

你能做什麼

如果你是工程師或貢獻者，別再找「最吵」的 crate，改找「最清楚」的 crate：最近有 release、review 有回應、測試覆蓋合理、維護者會回到具體問題。若你是 PM 或創辦人，請把數值依賴當成需要預算的維護項，不要只算功能開發成本。若你想幫 Rust 生態，最有效的切入點通常不是再開一個新 crate，而是替現有 crate 補 bug、補文件、補測試，讓它更像基礎設施，而不是展示品。