Rust エコシステムに、インタラクティブな REPL（Read-Eval-Print Loop）アプリケーションやカスタムシェルを構築するための新しいフレームワーク Shelgon が登場しました。このフレームワークは型安全なコマンド実行やリッチなターミナル UI 機能などの有望な機能を提供していますが、コミュニティでの議論はすぐに設計上の選択—特に非同期ランタイムの実装とエラー処理アプローチに関して—に集中しました。
Shelgon フレームワークの主な特徴
- 型安全なコマンド実行
- 非同期ランタイム統合（現在は Tokio ベース）
- ratatui を活用した TUI 機能
- 豊富な入力処理機能：
- コマンド履歴
- カーソル移動
- タブ補完
- Ctrl+C/Ctrl+D の処理
- カスタムコンテキストのサポート
- 複数行入力のための STDIN サポート
非同期ランタイムの依存性が議論を呼ぶ
フレームワークが Tokio を非同期ランタイムとして採用する決定は、潜在的なユーザーの間で大きな議論を生み出しました。複数の開発者が、なぜ非同期機能がオプション機能ではなく中核的な要件なのかについて疑問を投げかけました。特に洞察に富んだあるコメントでは、特定のランタイムを強制することへの懸念が強調されました：
「Tokio を使用していないのに、なぜ依存関係として追加する必要があるのでしょうか？」
この意見は、ランタイムに依存しないか、同期的な代替手段を提供するライブラリを好む Rust コミュニティの広範な嗜好を反映しています。フレームワークの作者（コメントでは cat-whisperer と特定）は、これらの懸念を認め、現在の実装ではユーザーがランタイムを渡すことでブロックまたはスケジューリング操作を選択でき、開発者に並行性の制御を与えていると説明しました。また、将来のバージョンでは非同期サポートをオプトイン機能にすることを検討していると述べています。
エラー処理アプローチへの疑問
もう一つの議論の的は、Shelgon のパブリック API で anyhow クレートを使用していることです。複数の開発者が、ライブラリは独自のエラータイプを定義するか、一般的にアプリケーションコードに適しているとされる anyhow ではなく thiserror を使用すべきだと提案しました。作者は、将来のアップデートで thiserror と error-stack を実装する予定があると回答しつつも、当初は anyhow を選んだ理由として、ユーザーがエラー処理よりもドメインロジックに集中できるようにするためのシンプルなインターフェースを提供するからだと説明しました。
ビジュアルデモの要請
Shelgon は ratatui クレートを活用した美しい TUI 機能を宣伝していますが、複数のコメンターがこれらの機能を示すスクリーンショットや動画がないことを指摘しました。多くのユーザーがビジュアル例を要求し、asciinema などのツールを使用してフレームワークのインターフェース機能を紹介することを提案しました。このフィードバックは、UI に焦点を当てたライブラリを宣伝する際のビジュアルデモンストレーションの重要性を強調しています。
コミュニティの懸念点
- 非同期ランタイム: 必須の Tokio 依存関係に対する疑問
- エラー処理: ライブラリ固有のエラー型ではなく anyhow を使用していること
- ドキュメント: UIに重点を置いているにもかかわらず視覚的な例が不足していること
- 命名: ポケモンの名前（ Shelgon ）を使用することに関する一部の懸念
既存のソリューションとの比較
議論では、Shelgon が Rust エコシステムの確立された代替手段（rustyline や reedline など）とどのように比較されるかについても触れられました。作者は rustyline のユーザーインタラクションに対する広範なサポートを認めつつも、Shelgon はトレイトベースのアプローチを通じてより制限的ながらも強力な抽象化を提供し、状態共有機能を維持しながらシェルの側面を正確に制御することを目指していると説明しました。
Shelgon は進化を続けており、作者はコミュニティからのフィードバックに対して受容的であり、貢献に対してオープンであることを示し、フレームワークがまだ活発に開発中であることを示唆しています。Rust でカスタム REPL 環境を構築することに興味がある開発者にとって、Shelgon は興味深い新しい選択肢を提供していますが、その設計上の選択は、異なるプロジェクト要件とどの程度一致するかによって採用に影響を与える可能性があります。
参考：Shelgon: A Rust Framework for Building Interactive REPL Applications