The Rust ecosystem has welcomed a new framework called Shelgon, designed for building interactive REPL (Read-Eval-Print Loop) applications and custom shells. While the framework offers promising features like type-safe command execution and rich terminal UI capabilities, the community discussion has quickly centered on architectural choices—particularly around its async runtime implementation and error handling approach.
Shelgon Framework Key Features
- Type-safe Command Execution
- Async Runtime Integration (currently Tokio-based)
- TUI capabilities powered by ratatui
- Rich Input Handling including:
- Command history
- Cursor movement
- Tab completion
- Ctrl+C/Ctrl+D handling
- Custom Context Support
- STDIN Support for multi-line input
Async Runtime Dependency Sparks Debate
The framework's decision to couple with Tokio as its async runtime has generated significant discussion among potential users. Several developers have questioned why async functionality is a core requirement rather than an optional feature. One particularly insightful comment highlighted concerns about forcing users to adopt a specific runtime:
Why would I want to add tokio as a dependency if I don't use it?
This sentiment reflects a broader preference in the Rust community for libraries that remain runtime-agnostic or provide synchronous alternatives. The framework's creator, identified in comments as cat-whisperer, acknowledged these concerns, explaining that the current implementation allows users to either block or schedule operations by passing in a runtime, giving developers control over concurrency. They also mentioned considering making async support an opt-in feature in future versions.
Error Handling Approach Questioned
Another point of contention is Shelgon's use of the anyhow crate for error handling in its public API. Multiple developers suggested that libraries should define their own error types or use thiserror instead of relying on anyhow, which is generally considered more appropriate for application code rather than libraries. The creator responded that while they plan to implement thiserror and error-stack in future updates, they chose anyhow initially because it provides a simpler interface that allows users to focus on domain logic rather than error handling.
Visual Demonstrations Requested
Despite Shelgon advertising beautiful TUI capabilities powered by the ratatui crate, several commenters noted the absence of screenshots or videos demonstrating these features. Multiple users requested visual examples, with suggestions for using tools like asciinema to showcase the framework's interface capabilities. This feedback highlights the importance of visual demonstrations when promoting UI-focused libraries.
Community Concerns
- Async Runtime: Mandatory Tokio dependency questioned
- Error Handling: Use of anyhow instead of library-specific error types
- Documentation: Lack of visual examples despite UI focus
- Naming: Some concerns about using a Pokémon name (Shelgon)
Comparisons to Existing Solutions
The discussion also touched on how Shelgon compares to established alternatives in the Rust ecosystem, such as rustyline and reedline. The creator acknowledged rustyline's extensive support for user interactions but explained that Shelgon aims to provide a more restrictive yet powerful abstraction through its trait-based approach, offering precise control over shell aspects while maintaining state sharing capabilities.
As Shelgon continues to evolve, the creator appears receptive to community feedback, indicating openness to contributions and suggesting that the framework is still in active development. For developers interested in building custom REPL environments in Rust, Shelgon represents an interesting new option, though its architectural choices may influence adoption depending on how they align with different project requirements.
Reference: Shelgon: A Rust Framework for Building Interactive REPL Applications