[catlifeonmars]

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.

[debugnik]

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.

[catlifeonmars]

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.

[debugnik]

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.