By this logic, Bash is a "polyglot task runner" too. With a shebang and executable permissions, I can run `./task1.py` or `./task2.js` or `./task3.sh`. I can also run inline tasks in various languages within a Bash script by piping the source into the appropriate interpreter.
I like and use `just`, but I think the project author's claims around it being "polyglot" are misusing the term.
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.
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.
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?
The idea is similar to IPython, which provides an interactive interface for programming languages. The motivation isn't about building a massive CLI tool—it's about questioning why we need a separate REPL for each language when we could use a single command-line interface that lets us switch between languages on the fly.
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.
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.
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.
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.
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".
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?
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.)
"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.
You're right—Kotlin can be used as Kotlin/JS for web development, and as a compiled language when we're talking about Android development.
Context matters
You're right—and the same applies to Kotlin. Swift is more like Rust, C, and C++ in that it compiles directly to machine code. So yes, Swift is currently listed under the wrong category.
As for Kotlin, it could reasonably be placed under either "Web & scripting" or "Compiled," depending on how it's used. Since Kotlin can also compile to JavaScript, its classification depends on the context. If we're talking about Android development, then Kotlin is clearly a compiled systems language.
To clarify: Swift is a compiled, statically typed systems language, much like Rust, C++, or Go. Its core toolchain (swiftc) compiles code into native binaries.
This is a quirky response. Kotlin might be able to compile to JS the same way C++ can compile to WASM but I don't think that's it's primary purpose. Either put them in their idiomatic category or don't bother categorizing at all.
> exposes a unified REPL experience with commands like :help, :lang, and :quit.
Those sound similar to "magic commands" in IPython and Jupyter?
There is not yet a
Jupyter-xeus Rust kernel which would make it really easy to support Rust in JupyterLite in WASM on an .edu Chromebook and in JupyterLab: https://news.ycombinator.com/item?id=43354177
> jupyter_console is the IPython REPL for non-ipykernel jupyter kernels. [like evcxr]
> This magic command logs IPython REPL input and output to a file:
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.
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...
By this logic, Bash is a "polyglot task runner" too. With a shebang and executable permissions, I can run `./task1.py` or `./task2.js` or `./task3.sh`. I can also run inline tasks in various languages within a Bash script by piping the source into the appropriate interpreter.
I like and use `just`, but I think the project author's claims around it being "polyglot" are misusing the term.
What makes just polyglot? Why not call out /usr/bin/env instead?
> 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.
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.
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?
The idea is similar to IPython, which provides an interactive interface for programming languages. The motivation isn't about building a massive CLI tool—it's about questioning why we need a separate REPL for each language when we could use a single command-line interface that lets us switch between languages on the fly.
Aren’t you just describing a shell ?
Isn't the whole point of a shebang line that scripts can identify for themselves what language/runner they want to be executed via?
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.
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.
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.
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.
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.
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".
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?
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.
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.)
"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.
You're right—Kotlin can be used as Kotlin/JS for web development, and as a compiled language when we're talking about Android development. Context matters
You're right—and the same applies to Kotlin. Swift is more like Rust, C, and C++ in that it compiles directly to machine code. So yes, Swift is currently listed under the wrong category.
As for Kotlin, it could reasonably be placed under either "Web & scripting" or "Compiled," depending on how it's used. Since Kotlin can also compile to JavaScript, its classification depends on the context. If we're talking about Android development, then Kotlin is clearly a compiled systems language.
To clarify: Swift is a compiled, statically typed systems language, much like Rust, C++, or Go. Its core toolchain (swiftc) compiles code into native binaries.
This is a quirky response. Kotlin might be able to compile to JS the same way C++ can compile to WASM but I don't think that's it's primary purpose. Either put them in their idiomatic category or don't bother categorizing at all.
I'm pretty sure OPs reply is direct from an LLM
most of replies from OP sure sound like it.
> exposes a unified REPL experience with commands like :help, :lang, and :quit.
Those sound similar to "magic commands" in IPython and Jupyter?
There is not yet a Jupyter-xeus Rust kernel which would make it really easy to support Rust in JupyterLite in WASM on an .edu Chromebook and in JupyterLab: https://news.ycombinator.com/item?id=43354177
> jupyter_console is the IPython REPL for non-ipykernel jupyter kernels. [like evcxr]
> This magic command logs IPython REPL input and output to a file:
https://news.ycombinator.com/item?id=25923123 ,Here's how to support something like _repr_html_() and IPython.display.display() with evcxr_jupyter: https://github.com/evcxr/evcxr/blob/main/evcxr_jupyter/READM...
I'm not sure what the pros and cons of evcxr_repr, jupyter_console + evcxr_jupyter, and Run are?
This is great! How hard is it to add more languages?
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.
It's simple. It was made by someone who's just starting out with Rust.