[saghm]

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.

[esubaalew]

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.

[saghm]

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.

[dicknuckle]

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.

[saghm]

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.