←back to thread

Show HN: Run – a CLI universal code runner I built while learning Rust

(github.com)
96 points esubaalew | 5 comments | 04 Oct 25 18:34 UTC | HN request time: 0s | source

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.

Show context
Surac ◴[04 Oct 25 20:10 UTC] No.45476300[source]▶
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?
replies(2): >>45476780 #>>45477665 #
ForHackernews ◴[04 Oct 25 21:16 UTC] No.45476780[source]▶
Isn't the whole point of a shebang line that scripts can identify for themselves what language/runner they want to be executed via?
replies(1): >>45476900 #
1. saghm ◴[04 Oct 25 21:31 UTC] No.45476900[source]▶
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.

replies(1): >>45477705 #
2. esubaalew ◴[04 Oct 25 23:35 UTC] No.45477705[source]▶
Yes, that's exactly the point. What I'm trying to do is: 1. Use Rust because it's fast. 2. Make REPLs universal, so we don't need separate REPLs for different languages. 3. And third—though not a new idea—is to create better abstractions, like allowing print statements without requiring a main function, and accessing variables without explicitly printing them.
replies(2): >>45477913 #>>45478354 #
3. dicknuckle ◴[05 Oct 25 00:19 UTC] No.45477913[source]▶
How much time are you saving for each invocation? My 10 year old laptop invokes /usr/bin/env in less time than an HTTPS handshake.
replies(1): >>45478350 #
4. saghm ◴[05 Oct 25 02:10 UTC] No.45478350{3}[source]▶
How do you download and manage the various language toolchains though? At least in my experience, the ease of doing this varies quite a bit by language and OS. Some distros have better package managers than others, and some of them don't have first-party ones at all. If I want to install Python on MacOS and haven't been using it enough to know which of the half dozen or so tools that are recommended by various people for it (or might have a sense of what to use but lack interest in learning the specifics of yet another tool for a language I need to do something fairly basic in), having a single tool that I'm already using for a bunch of other languages that I can also use for Python might be pretty nice.
5. saghm ◴[05 Oct 25 02:12 UTC] No.45478354[source]▶
That makes a lot of sense to me! I imagine that a lot of the logic you'll define will be fairly independent of the language itself, so you won't need to do quite as much work as if each one were implemented separately.