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?
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.
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.
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.
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?
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.
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.
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.