←back to thread

96 points esubaalew | 4 comments | | 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
garganzol ◴[] No.45477842[source]
If someone is interested in pursuing this approach further, there exist a polyglot task runner named 'just' [1].

[1] https://github.com/casey/just?tab=readme-ov-file#shebang-rec...

replies(2): >>45478479 #>>45478619 #
catlifeonmars ◴[] No.45478479[source]
What makes just polyglot? Why not call out /usr/bin/env instead?
replies(1): >>45478579 #
debugnik ◴[] No.45478579[source]
> What makes just polyglot?

The link they shared and you didn't open, which is precisely an example of multiple recipes with different #!/usr/bin/env shebang lines, such that a single just file can mix different languages.

I'm not sure I like how they handle the shebang on different platforms, though. It makes just files non-portable even when using a language other than a shell.

replies(1): >>45478634 #
1. catlifeonmars ◴[] No.45478634[source]
I did open the link. I use just in a couple of projects and it’s great. Calling just “polyglot” because it can call another program is nonsensical. I might as well call bash, make, and even VSCode (task runners) polyglot.

If the program hosted its own interpreters for multiple scripting languages, then it would make sense to call it polyglot.

replies(1): >>45480967 #
2. debugnik ◴[] No.45480967[source]
I agree the shebangs are a blunt solution, but I'll give them polyglot for embedding arbitrary languages under the recipe syntax without having to shell out with a heredoc. It's a low bar, but I can't think of any alternative that clears it and I don't think there's any value in hosting the interpreter unless there's some particular API to expose to it.

Also, you wrote "Why not call out /usr/bin/env instead?" which is exactly what the example was doing, so I assumed your own proposal would have seemed sufficient to you, had you seen it.

replies(1): >>45482162 #
3. catlifeonmars ◴[] No.45482162[source]
Fair, I intended my initial comment as mild sarcasm. In the sense that if this counts as polyglot, then what does the term mean anyway?

But I feel I’ve come around to your perspective. Mine was overly pedantic.

replies(1): >>45489400 #
4. debugnik ◴[] No.45489400{3}[source]
In retrospect my replies have also been harsher than they should have, I didn't contribute to a good mood. Most IT nomenclature is poorly made up anyway, what does polyglot even mean indeed.

As I said, I don't even like Just's approach as it isn't even cross platform, but I guess solving this properly would require tying the recipe runner to a package repository per platform. I still appreciate that Just tried to make it a legible built-in feature though.