Rust 生態系統迎來了一個名為 Shelgon 的新框架，該框架旨在構建互動式 REPL（讀取-求值-列印迴圈）應用程式和自定義 shell。雖然該框架提供了型別安全的命令執行和豐富的終端 UI 功能等有前景的特性，但社群討論很快就集中在了架構選擇上——特別是關於其非同步執行時實現和錯誤處理方法。
Shelgon 框架主要特點
- 型別安全的命令執行
- 非同步執行時整合（目前基於 Tokio）
- 由 ratatui 提供支援的 TUI 功能
- 豐富的輸入處理功能，包括：
- 命令歷史記錄
- 游標移動
- Tab 自動補全
- Ctrl+C/Ctrl+D 處理
- 自定義上下文支援
- 支援多行輸入的 STDIN
非同步執行時依賴引發爭論
該框架決定與 Tokio 作為其非同步執行時繫結的做法引發了潛在使用者中的重要討論。一些開發者質疑為什麼非同步功能是核心需求而不是可選功能。一條特別有見地的評論強調了強制使用者採用特定執行時的擔憂：
「如果我不使用 tokio，為什麼我要新增它作為依賴項？」
這種觀點反映了 Rust 社群中更廣泛的偏好，即庫應該保持執行時不可知或提供同步替代方案。該框架的建立者，在評論中被稱為 cat-whisperer，承認了這些擔憂，解釋說當前的實現允許使用者透過傳入執行時來阻塞或排程操作，從而讓開發者控制併發。他們還提到考慮在未來版本中將非同步支援作為一個可選功能。
錯誤處理方法受到質疑
另一個爭議點是 Shelgon 在其公共 API 中使用 anyhow 庫進行錯誤處理。多位開發者建議，庫應該定義自己的錯誤型別或使用 thiserror，而不是依賴 anyhow，後者通常被認為更適合應用程式程式碼而非庫。建立者回應說，雖然他們計劃在未來更新中實現 thiserror 和 error-stack，但他們最初選擇 anyhow 是因為它提供了更簡單的介面，允許使用者專注於領域邏輯而非錯誤處理。
要求視覺演示
儘管 Shelgon 宣傳了由 ratatui 庫支援的精美 TUI 功能，但一些評論者指出缺少展示這些功能的截圖或影片。多位使用者要求提供視覺示例，並建議使用 asciinema 等工具來展示框架的介面功能。這一反饋突顯了在推廣以 UI 為重點的庫時視覺演示的重要性。
社群關注點
- 非同步執行時：對強制依賴 Tokio 的質疑
- 錯誤處理：使用 anyhow 而非庫特定的錯誤型別
- 文件：儘管專注於UI，但缺乏視覺化示例
- 命名：一些關於使用寶可夢名稱（Shelgon）的擔憂
與現有解決方案的比較
討論還涉及 Shelgon 如何與 Rust 生態系統中的成熟替代品（如 rustyline 和 reedline）進行比較。建立者承認 rustyline 對使用者互動的廣泛支援，但解釋說 Shelgon 旨在透過其基於特性的方法提供更嚴格但功能更強大的抽象，在維持狀態共享能力的同時提供對 shell 各方面的精確控制。
隨著 Shelgon 的不斷發展，建立者似乎對社群反饋持開放態度，表示願意接受貢獻，並暗示該框架仍在積極開發中。對於有興趣用 Rust 構建自定義 REPL 環境的開發者來說，Shelgon 代表了一個有趣的新選擇，儘管其架構選擇可能會根據不同專案需求的匹配程度影響其採用。
參考：Shelgon: A Rust Framework for Building Interactive REPL Applications