[HN Gopher] Show HN: Shelgon: A Framework for Building Interacti...
       ___________________________________________________________________
        
       Show HN: Shelgon: A Framework for Building Interactive REPL Shells
       in Rust
        
       I've been working on Shelgon, a framework that lets you build your
       own custom REPL shells and interactive CLI applications in Rust.
       You can use Shelgon to:  - Create a custom shell with only a few
       lines of code - Build interactive debugging tools with persistent
       state between commands - Develop domain-specific language
       interpreters with shell-like interfaces - Add REPL capabilities to
       existing applications  Getting started is straightforward -
       implement a single trait that handles your command execution logic,
       and Shelgon takes care of the terminal UI, input handling, and
       async runtime integration.  For example, a simple echo shell takes
       less than 50 lines of code, including a full implementation of
       command history, cursor movement, and tab completion.  Repository:
       https://github.com/nishantjoshi00/shelgon
        
       Author : cat-whisperer
       Score  : 58 points
       Date   : 2025-03-06 19:32 UTC (3 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | hkalbasi wrote:
       | How it compares to other libraries in this space, e.g. reedline
       | or rustyline?
        
       | Y_Y wrote:
       | That's a one-liner in lisp
        
         | gertlex wrote:
         | Classic bagon comment! :)
        
       | cmrdporcupine wrote:
       | Neat. I'll check it out.
       | 
       | One suggestions: the README advertises lovely TUIs. Show us a
       | screenshot, or screencast, so we can see what you mean!
        
         | tmpfs wrote:
         | Yes, a screenshot would be good to get a visual on this.
         | 
         | I have done a simple shell using Rustyline and Clap and this
         | could be something I might be interested in but it's hard to
         | say without a visual idea, asccinema would be perfect!
        
       | bfLives wrote:
       | Looks really interesting. I like the approach of writing pure
       | functions that return descriptions of IO tasks to perform. A
       | couple of questions:
       | 
       | 1. Why async?
       | 
       | 2. Why couple to anyhow instead of using an associated error
       | type?
        
         | cmrdporcupine wrote:
         | +1 for #1. In general, I would recommend providing non-async
         | alternative APIs, with the async runtime as an _option_ rather
         | than assumed default. Not all of us drink the kool-aid there.
         | And no, I don 't mean just providing a "sync" API that uses
         | "block_on" behind the scenes but still uses tokio...
         | 
         | Also, for async don't mandate tokio, use the "agnostic" crate
         | to abstract it so people can use alternative runtimes.
         | 
         | And yes, don't use anyhow in a library like this. Anyhow is for
         | your internal code, not public libraries/crates. Define a set
         | of error enums, or use thiserror for it if you have to.
        
       | ilikegreen wrote:
       | Please don't mind my possibly simplistic question -- but is this
       | something that would bring Rust development closer to a Lisp
       | environment? Seems like an interesting project.
        
       | jiaaro wrote:
       | Cool project! But, I wonder how long can a project like this use
       | a Pokemon as their namesake and mascot before you hear from
       | nintendo's lawyers?
        
         | dartos wrote:
         | Right up until they start charging
        
       ___________________________________________________________________
       (page generated 2025-03-06 23:00 UTC)