I’ve been looking around for a scripting language that:

  • has a cli interpreter
  • is a “general purpose” language (yes, awk is touring complete but no way I’m using that except for manipulating text)
  • allows to write in a functional style (ie. it has functions like map, fold, etc and allows to pass functions around as arguments)
  • has a small disk footprint
  • has decent documentation (doesn’t need to be great: I can figure out most things, but I don’t want to have to look at the interpter source code to do so)
  • has a simple/straightforward setup (ideally, it should be a single executable that I can just copy to a remote system, use to run a script and then delete)

Do you know of something that would fit the bill?

Here’s a use case (the one I run into today, but this is a recurring thing for me).

For my homelab I need (well, want) to generate a luhn mod n check digit (it’s for my provisioning scripts to generate synchting device ids from their certificates).

I couldn’t find ready-made utilities for this and I might actually need might a variation of the “official” algorithm (IIUC syncthing had a bug in their initial implementation and decided to run with it).

I don’t have python (or even bash) available in all my systems, and so my goto language for script is usually sh (yes, posix sh), which in all honestly is quite frustrating for manipulating data.

  • gompOP
    4·
    18 days ago

    Installing node uses some 60MB (according to zypper on my current desktop). I’d rather have something small and possibly that consists of a single executable.

    As a bonus, both support the vast and extensive NPM package repository

    That’s not necessarily a feature :) Package repos are great if you are a developer (I am one) working primarily with that language, but are frustrating if you just want to run things.

    • bruce965
      1·
      16 days ago

      I thought so. Although almost nothing for modern standards, 60MB is not exactly tiny. Sorry about that.

      On a different note, a repository is always a good thing imho. If you’d rather not have to worry about the dependency-pull step you can always include the dependencies with your sources, or just limit your code to using features included in the standard library.