[HN Gopher] Show HN: Run - a CLI universal code runner I built w...
       ___________________________________________________________________
        
       Show HN: Run - a CLI universal code runner I built while learning
       Rust
        
       Hi HN -- I'm learning Rust and decided to build a universal CLI for
       running code in many languages. The tool, Run, aims to be a single,
       minimal dependency utility for: running one-off snippets (from CLI
       flags), running files, reading and executing piped stdin, and
       providing language-specific REPLs that you can switch between
       interactively.  I designed it to support both interpreted languages
       (Python, JS, Ruby, etc.) and compiled languages (Rust, Go, C/C++).
       It detects languages from flags or file extensions, can compile
       temporary files for compiled languages, and exposes a unified REPL
       experience with commands like :help, :lang, and :quit.  Install:
       cargo install run-kit (or use the platform downloads on GitHub).
       Source & releases: https://github.com/Esubaalew/run  I used Rust
       while following the official learning resources and used AI to
       speed up development, so I expect there are bugs and rough edges.
       I'd love feedback on: usability and UX of the REPL, edge cases for
       piping input to language runtimes, security considerations
       (sandboxing/resource limits), packaging and cross-platform
       distribution.  Thanks -- I'll try to answer questions and share
       design notes.
        
       Author : esubaalew
       Score  : 44 points
       Date   : 2025-10-04 18:34 UTC (4 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | not--felix wrote:
       | This is great! How hard is it to add more languages?
        
         | nick__m wrote:
         | Looking at the code it appears to be somewhat easy, you add
         | your language to language.rs and in the engine folder you add
         | yourlang.rs where you provide an implementation of the
         | LanguageEngine trait for the YourLangEngine struct.
         | 
         | It would be less tedious if some code was factored out into an
         | Helper struct but it doesn't look like it's hard.
        
       | brandonasuncion wrote:
       | As a small note, Swift is a compiled language. It uses LLVM as a
       | backend, same as Rust and Clang (C/C++/ObjC). It's currently
       | listed under "Web & typed scripting".
        
         | jayrhynas wrote:
         | It's definitely a blurry line, this `run` tool invokes your
         | Swift file with `swift file.swift` which runs it in immediate
         | mode. Technically it is compiling your code to memory and and
         | immediately executing it, but is it that different from JIT in
         | Python or Node scripting?
        
           | brandonasuncion wrote:
           | If you look at it that way, I agree. But then the same thing
           | is done for executing Go, which is listed with the other
           | compiled languages.
        
             | saghm wrote:
             | I wonder if the mistake might stem from Go using a
             | subcommand (i.e. `go run`, which might appear resemble
             | `cargo run` or `dotnet run` at a glance) compared to
             | providing the ability to run a "script" as a top-level
             | command, which tends to be more common with interpreted
             | languages (`node`, `python`, `irb`, `bash`, `lua`, etc.)
        
             | likeclockwork wrote:
             | "compiled" isn't a property of a language. I think the
             | distinction that both you and the author of the tool are
             | making is always going to be messy. It seems to me that
             | you're talking about the language itself via an imprecise
             | description of a particular implementation.
        
       | Surac wrote:
       | I am very intrested why you choose to write such a tool. i
       | normaly have a hand full of shell scripts doing the work, but
       | surly i have to know the used language befor i call the script.
       | Can you explain the motivation?
        
         | ForHackernews wrote:
         | Isn't the whole point of a shebang line that scripts can
         | identify for themselves what language/runner they want to be
         | executed via?
        
           | saghm wrote:
           | Yeah, this seems to me to be comparable to something like
           | `/usr/bin/env` or even agnostic language package managers
           | like asdf in terms of trying to provide an abstraction over
           | having to manually define where to find the toolchain to use
           | for a given script. There's a pretty well-established pattern
           | at this point of alternate takes for common CLI tools being
           | written in Rust that bring something interesting to the table
           | at the cost of compatibility with the older existing tool, so
           | even if this one might or might not pan out into being useful
           | for enough people, I think it's totally reasonable to try to
           | come up with a new way of doing things.
           | 
           | It's also not incredibly uncommon for people to run scripts
           | that they haven't written themselves (like via the almost
           | universally reviled but still somewhat common `curl <...> |
           | bash` installation pattern). It probably would be better if
           | things didn't get installed like this, but if it's going to
           | happen, it might be nice to have the scripts written in
           | something less annoying than shell so that the authors could
           | at least use the same language for the installation script
           | that they do for writing the software itself.
        
       ___________________________________________________________________
       (page generated 2025-10-04 23:00 UTC)