Recommend me a scripting language

gomp@lemmy.ml to Linux@lemmy.ml – 109 points –

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.

139

Why aren't python and bash be available in all your systems? Which languages would be?

I would've recommended python, otherwise perl or Haskell (maybe Haskell's too big) or something, but now I'm worried that whatever reason makes python undoable also makes perl etc. undoable

Mate, I came on here to post Haskell as a semi-ironic 'joke' and it's included in the top comment. You've made my day.

I mean, it's a functional programming language and an incredibly good one. But it probably has a far too big footprint for their use-case...

Why aren’t python and bash be available in all your systems?

Among others, I run stuff on alpine and openwrt.

I don't need to run these scripts everywhere (strictly speaking, I don't need the homlab at all), but I was wondering if there's something that I can adopt as a default goto solution without having to worry about how each system is packaged/configured.

As for python, I doubt the full version would fit in my router plus as said I don't want to deal with libraries/virtualenvs/... and (in the future) with which distro comes with python3 vs pyton4 (2 vs 3 was enough). Openwrt does have smaller python packages, but then I would be using different implementations on different systems: again something I'd rather not deal with.

As for perl, it would be small enough, but I find it a bit archaic/esoteric (prejudice, I know), plus again I don't want to deal with how every distro decides to package the different things (eg. openwrt has some 40+ packages for perl - if I were doing serious development that would be ok, but I don't want to worry about that for just some scripts).

Sounds like you want MicroPython. It’s definitely available on OpenWrt and AlpineLinux and has a very small footprint.

If you don’t like Python, have a look at Lua/luajit.

You've defined yourself into an impossible bind: you want something extremely portable, universal but with a small disk imprint, and you want it to be general purpose and versatile.

The problem is that to be universal and general purpose, you need a lot of libraries to interact with whatever type of systems you might have it on (and the peculiarities of each), and you need libraries that do whatever type of interactions with those systems that you specify.

E.g. under-the-hood, python's open("", 'r') is a systemcall to the kernel. But is that Linux? BSD? Windows NT? Android? Mach?

What if you want your script to run a CLI command in a subshell? Should it call "cmd"? or "sh"? or "powershell"? Okay, okay, now all you need it to do is show the contents of a file... But is the command "cat" or "type" or "Get-FileContents"?

Or maybe you want to do more than simple read/write to files and string operations. Want to have graphics? That's a library. Want serialization for data? That's a library. Want to read from spreadsheets? That's a library. Want to parse XML? That's a library.

So you're looking at a single binary that's several GBs in size, either as a standalone or a self-extracting installer.

Okay, maybe you'll only ever need a small subset of libraries (basic arithmetic, string manipulation, and file ops, all on standard glibc gnu systems ofc), so it's not really "general purpose" anymore. So you find one that's small, but it doesn't completely fit your use case (for example, it can't parse uci config files); you find another that does what you need it to, but also way too much and has a huge footprint; you find that perfect medium and it has a small, niche userbase... so the documentation is meager and it's not easy to learn.

At this point you realize that any language that's both easy to learn and powerful enough to manage all instances of some vague notion of "computer" will necessarily evolve to being general purpose. And being general purpose requires dependencies. And dependencies reduce portability.

At this point your options are: make your own language and interpreter that does exactly what you want and nothing more (so all the dependencies can be compiled in), or decide which criteria you are willing to compromise on.

Is compiling scripts an option? Aka compiling them in C, C++, Rust, whatever for your router on another machine, and copying and executing those binaries on your router?

You might be interested in Raku. It is Perl6, or what used to be called Perl6, but it deviated too far away from the original perl and it ended up with a different team of developers than perl 5, so they forked it, changed the name and turned it into a new language.

if there's something that I can adopt as a default goto solution without having to worry about how each system is packaged/configured.

Go is probably your best bet. Simple to use, and you can compile it so it runs everywhere

I found installing Go-sdk a total PiTA. It is okay as a developer environment. But bash + gnu utils + core utils seem much more sane to me.

Of course I mostly work with Linux systems and hardly ever have to deal with Scripting for Windoze.

luajit is small, fast(well, it can jit), and has a small but complete standard library and can do FFI pretty easily, should be ideal for most homelab usecase

ldd $(which luajit)                                                                                
        linux-vdso.so.1 (0x00007ffee9dc7000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb4db618000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb4db613000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb4db5f3000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb4db3ca000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb4db799000)

Python is what you want. You can install it on just about any system.

Other than that maybe Lua but that will be hell.

Python is what you want. You can install it on just about any system.

Perl and bash are already there, no need to install anything.

Perl isn't normally preinstalled by Python is. (On Linux)

Try it now - go on. Type "perl" and tell me what you get.

And if you're so certain it's not used, try removing it and see how well your computer works afterwards.

It isn't installed

I know that because I installed it as it was a dependency of Buildroot.

Edit: My bad I must of been thinking about a Perl library

If you just run perl it will sit waiting for input. Try perl --version

Once git no longer depends on it, it'll be gone from my system

Is this the case? I don't feel like I've ever had to install Perl but I've had to install Python plenty of times and I use both pretty frequently on a daily basis. Not to mention a newer version, older version, 2.7.4 instead of 2.7.3.

Um, exactly the opposite on all the distros I use. All Enterprise Linux distros, Suse and Debian.

Perl is already installed on most linux machines and unless you start delving into module usage, you won't need to install anything else.

Python is more fashionable, but needs installing on the host and environments can get complicated. I don't think it scales as well as Perl, if that's a concern of yours.

What about Lua/Luajit?

In most scripting languages you have the interpreter binary and the (standard) libraries as separate files. But creating self-extracting executables, that clean up after themselves can easily be done by wrapping them in a shell script.

IMO, if low dependencies and small size is really important, you could also just write your script in a low level compiled language (C, Rust, Zig, ...), link it statically (e.g. with musl) and execute that.

I use Lua for this sort of thing. Not my favorite language, but it works well for it. Easy to build for any system in the last 20-30 years, and probably the next 20 too. The executable is small so you can just redistribute it or stick it in version control.

Micropython.

That does seem to be just one, maybe two small files, and no dependencies. And a built in map() function.

I can’t really think of anything that’s less frustrating than sh and ticks all your boxes. You can try TCL but it’s bound to be a shit show. It was painful to use two decades ago.

Perl is a step up in terms of developer comfort, but it’s at the same time too big and too awkward to use.

Maybe a statically linked Python?

I was thinking about recommending TCL as a joke. My favorite thing about it is it's "whimsicly typed."

Perl is a step up in terms of developer comfort, but it’s at the same time too big and too awkward to use.

How do you mean?

It's already on nearly every distro, so there's no core size unless you lean into modules. The scripts aren't exactly big either.

He doesn’t have bash. I’m not sure I’ve seen a system this millennium with Perl but not bash.

Try it now - type perl. It's a dependency on a huge amount of core system tools.

OP is on OpenWRT (a router distro), and Alpine. Those distros don't come with very much by default, and perl is not a core dependency for any of their default tools. Neither is python.

Based on the way the cosmo project has statically linked builds of python, but not perl, I'm guessing it's more difficult to create a statically linked perl. This means that it's more difficult to put perl on a system where it isn't already there, and that system doesn't have a package manager*, than python or other options.

*or the the user doesn't want to use a package manager. OP said they just want to copy a binary around. Can you do that with perl?

OP is on OpenWRT

Fair point - I missed that, buried in the comments as it was.

In that scenario, you use what's available, I guess.

OP said they just want to copy a binary around. Can you do that with perl?

This is linux. Someone will have done it.

another vote for Lua – lua5.4 is available for all 8 Alpine architectures, tiny installed size (120–200 kB) (and Alpine package only installs two files)

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.

Why are you making it hard on yourself? apt/dnf install a language to use and use it.

Realistically whatever problems you see in python will be there for any other language. Python is the most ubiquitously available thing after bash for a reason.

Also you mentioned provisioning scripts, is that Ansible? If so python is already there, if you mean really just bash scripts I can tell you that does not scale well. Also if you already have some scriptsz what language are they on? Why not write the function there?

Also you're running syncthing on these machines, I don't think python is larger than that (but I might be wrong).

Also you mentioned provisioning scripts, is that Ansible? If so python is already there, if you mean really just bash scripts I can tell you that does not scale well. Also if you already have some scriptsz what language are they on? Why not write the function there??

Currently it's mostly nixos, plus a custom thing that generates preconfigured openwrt images that I then deploy manually. I have a mess of other vms and stuff, but I plan to phase out everything and migrate to nixos (except the openwrt stuff, since nixos doesn't run on mips).

I don't really need to run this specific synchthing-ID script except on my PC (I do the provisioning from there), but I have written scripts that run on my router (using busybox sh) and I was wondering if there is a "goto" scripting that I can use everywhere.

Only 5 years ago, everybody would be singing and shouting "perl".

Nowadays it is python that has taken this position (even though Perl is still there and can do so much more).

More like

20 years ago - perl

10 years ago - python

Nowadays - go

Go isn't a scripting language

Go isn’t a scripting language, and it isn’t a system language either, despite what Wikipedia currently says. To be a system language, a language should support assembly language and shouldn’t require an embedded garbage collector. And if you’re going to make a compiled language anyway, why not make it capable of system work? Go is a platypus that’s popular with devops for some reason—probably Google’s clout in the industry.

Perl is a pain to work with

Python is a lot less pain

Even after using CPAN ? I found Perl to be much more "manageable" than Python.

Python with Venv and Pip at least works as expected. Which makes it easier.

Python has a clean syntax and is popular. I can't say the same for Perl. Also I'm not sure if Perl is cross platform.

Why would you say that Perl “can do so much more” than Python? That assertion sounds indefensible.

I honestly love Powershell, but haven't tried the Linux version yet. I only use Bash on linux but it has a load of odd quirks that make it unpleasant to use imo. Can't comment on anything else.

I use powershell for work as I need the m365 modules for work and its very flexible with decent module availability to plug in all sorts.

However it absolutely sucks for large data handling, anything over 10k rows is just horrendous, I typically work with a few million rows. You can make it work with using .Net to process it within your script but its something to be aware of. Being able to extend with .Net can be extremely useful.

The smallest footprint for an actual scripting probably will be posix sh - since you already have it ready.

A slightly bigger footprint would be Python or Lua.

If you can drop your requirement for actual scripting and are willing to add a compile step, Go and it's ecosystem is pretty dang powerful and it's really easy to learn for small automation tasks.

Personally, with the requirement of not adding too much space for runtimes, I'd write it in go. You don't need a runtime, you can compile it to a really small zero dependency lib and you have clean and readable code that you can extend, test and maintain easily.

No one has mentioned PHP yet? Man, times really have changed.

I used it for scripting a decade after everyone else, but even I have to admit PHP is rarely the best choice now.

For data processing?

Yeah, it's really flexible when it comes to arrays and string processing. Super easy to work with, too.

I've actually tried using PHP on OpenWRT and embedded before. It's not exactly lightweight, it's a memory and CPU hog. Keep in mind that the kind of machine that runs OpenWRT might only have 32 or even 16 MB of RAM to work with.

Also, PHP is not the first language that comes to mind when doing data processing and/or functional programming. You can but it doesn't lend itself well to it.

I still love bash. I'm able to accomplish quite a lot with it. I vote bash.

Also vote bash, but I don't love it..more of a tolerate.

Bash? On windows it's pretty much unusable even if you use cygwin. Python or Lua are the only reasonable suggestions here

Nah, gross. You need to set a bunch of global options to get sane behavior on errors.

Nushell is shaping up really really nicely, and it'll actually stop executing if something fails! Even if that happens in a pipe! And it's not super eager to convert between arrays and strings if you use the wrong cryptic rune.

I don't know if it matches your desire for easy install of small disk space, but it might make up for it in other arenas - Ruby is my new-found love when making simple scripts. Being able to mostly emulate the shell integration that bash has by just using backticks to call a shell command is the killer feature in my book.

Technically, you could bundle a Perl script with the interpreter on another system using pp and run the packed version on systems with no installed Perl, but at that point you might as well just use a compiled language.

Not quite a scripting language, but I highly recommend you check out cosmo for your usecase. Cosmopolitan, and/or Actually Portable Executable (APE for short) is a project to compile a single binary in such a way that is is extremely portable, and that single binary can be copied across multiple operating systems and it will still just run. It supports, windows, linux, mac, and a few BSD's.

— this is where you can download precompiled binaries of certain things using cosmo.

From my testing, the APE version of python works great, and is only 34 megabytes, + 12 kilobytes for the ape elf interpreter.

In addition to python, cosmopolitan also has precompiled binaries of:

  • Janet 2.5 MB
  • Berry 4.0 MB
  • Python 34 MB
  • Php 11 MB
  • Lua 2.1 MB
  • Bash 5.1 MB

And a few more, like tclsh, zsh, dash or emacs (53 MB), which I'm pretty sure can be used as an emacs lisp intepreter.

And it should be noted these may require the ape elf interpeter, which is 12 kilobytes, or the ape assimilate program, which is 476 kilobytes.

EDIT: It also looks like there is an APE version of perl, and the full executable is 24 MB.

EDIT again: I found even more APE/cosmo binaries:

Maybe something like Elvish or Nushell could be worth a look. They have a lot of similarities to classic shells like bash, but an improved syntax and more powerful features. Basically something in between bash and Python. Not sure about disk footprint or general availability/portability though

Powershell, yeah I said it!

Wanted to say this too but it really depends on what you're using it for.

Unironically Powershell is great and learning it has propelled me through the last 12 years of my career as a Sysadmin. My biggest complaints with it are generally Windows complaints or due to legacy powershell modules.

Only good on Windows

Oh dude, you are so wrong!

Powershell is available for linux and will run the same modules that have made it such a success on Windows. Want to fire up vmware containers or get a list of vms? Want to talk to Exchange servers? Azure? AWX? $large-corporate-thing? Powershell is a very good tool for that, even if it smells very Microsofty.

The linux version works well - it has some quirks (excessive logging, a MS repo that needs manual approving that breaks automatic updates) but aside from those, it just works. I have several multi-year scripts that tick away nicely in the background.

The key features are missing. Powershell is great for active directory and LDAP. You don't get that on Linux. It is just is a pain. Power shell is normally a pain but using on Linux is worse.

Can't say I've noticed much pain beyond what I mention - powershell just works.

Powershell evolved well beyond AD and LDAP a long time ago. Objects on the pipeline are a game changer.

If you can, just use Perl. Probably installed on your systems, even the ones without python.

So often the right answer, perl. It's a shame that it's so unfashionable these days.

I've looked into this a lot actually. There see many options. I'll highlight the pros and cons of each option.

Lua: extremely lightweight, but standard library is lacking, and doesn't include stuff like map or fold. But that would be easy to fix.

Python: thicc standard library, but is not lightweight by any means. There are modifications made to be more shell like, such as xonsh

Rash: based on scheme, very much functional but if you're not used to lisp style, might take a bit to get used to it. This is actually my favorite option. It has a cli interpreter, and really pleasant to use. Cons is... Well it's not very common

You can honestly use any language. Even most compiled languages have a way to run immediately.

A scripting language written in Rust would certainly fulfill you requirement of only needing to copy one file since they are always statically linked and you can even statically compile against musl so it will work on any Linux system without needing a correct libc. Maybe check out rhai.

JavaScript through Node.js, or TypeScript through Deno if you like typed languages. They both check all your boxes (just check the size of the executables to make sure that it's what you would consider "small footprint").

Both languages and runtimes are quite popular, so you will find any answers on StackOverflow.

They are both single-executable with little dependencies, and Deno can also compile your scripts to self-contained executables.

As a bonus, both support the vast and extensive NPM package repository where you can find all sort of libraries for even the most complex tasks.

And they work with your favourite IDE or editor, not just syntax highlighting, but also contextual suggestions.

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.

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.

As a Java developer, and someone who never learned Python or other scripting languages, Node is my go-to scripting language. I've only come around to it for that in the past year or two. But it's great.

Tried bash, Make, and awk/sed. All hit brick walls. Finally landed on pyinvoke. Two dependencies to install on any new machine. Never had problems. Also, easy to debug and modify as projects evolve.

I use just for that usecase - highly recommended

@gomp I like TypeScript.

I used Python for 15 years or so until they changed from v2 to v3. At that point I realised I couldn't understand my old code because it lacked types, so I got discouraged with that. So rather than learn v3 I stopped using it.

Perl is a disaster. sh is good for shell scripts but let's not stretch it.

TypeScript can use all the JS libraries and runs on node which is supported by all sorts of platforms. Yes there are a few holes in the type safety, so don't do that.

The internet is full of "how to do X in JS". You can read them and add the types you need.

I would go with Guile, because it is built-in to the Guix Package Manager which is a really good general-purpose package manager.

It ticks several of your boxes:

  • has a CLI interpreter
  • is a general purpose language, Scheme, amd compliant with revisions 5, 6, and 7 of the language standard
  • allows writing in a functional style (it is one of the original functional programming languages)
  • small disk footprint, but still large enough to be "batteries included"
  • decent documentation, especially if you use Emacs
  • simple setup: not so much, unless you are using Guix to begin with. The standard distribution ships with lots of pre-built bytecode files, you need an installer script to install everything.

It also has pretty good libraries for system maintenance and reporting:

Since you like guile, I would recommend you checkout rash (search "rash shell language" on Google. Sorry too lazy to link it).

It is based on racket, but made to be shell-like, and is very nice. I believe guile used to have a similar project that isn't maintained anymore.

Python.

Just remember to use pyenv for interpreter installation, version and environment management. It's pretty straightforward that way and you have predictability.

Don't ever manually fiddle with the system python and/or libraries or you'll break your system. You should just rely on the package manager for that.

Elixir checks most of those boxes. If you want a good functional scriptibg language, Elixir soynds like the go to. Some lisp language like guile should also be sufficient, and probably have a lighter footprint.

This requirement stands out though:

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)

Thats basically what ansible does. If you plan on doing this to multiple machines you should just use ansible. Also how do you plan on ensuring the scripting interpreter is installed on the machines?

Elixir is quite big (yeah, it's certainly smaller than something like java... sorry for not specifying what I mean by "small disk footprint").

Thats basically what ansible does. Thats basically what ansible does. If you plan on doing this to multiple machines you should just use ansible.

Ansible requires python on the target machine (or a lot of extra-hacky workarounds) so... I could just use python myself :)

BTW getting ansible to do anything besides the very straightforward usecases it was meant for is a huge pain (even a simple if/else is a pain) and it's also super-slow, so I hate it passionately.

Also how do you plan on ensuring the scripting interpreter is installed on the machines?

Ideally I'd just copy the interpreter over via ssh when needed (or install it via the local package manager, if it's available as a package)

If python is too big for you and you're dealing with heterogeneous systems then you're probably stuck with sh as the lowest common denominator between those systems. I'm not aware of any scripting languages that are so portable you can simply install them with one file over scp.

Alternate route is to abandon a scripting interpreter completely and compile a static binary in something like Go and deploy the binary.

There was also some "compile to bash" programming languages that I've sneered at because I couldn't think of a use case but this might be one.

If you are interested in tiny lisp like languages, this gitlab could be of interest to you.

Full disclaimer, I came across it a few years back as I am the maintainer of arkscript (which will get faster and better in the v4, so that data about it there is accurate as a baseline of « it should be at least this good but can be even better now »).

Perl or python for things likely to already be there. Maybe ruby or PHP if you must. I used to work in groovy a lot but I think it requires the JVM

Perl requres the perl interpreter and python requires a python interpreter. Why is it bad that groovy also needs a vm?

Perl's core to most distros and will be there already. Python isn't and can be quite heavy - plus some of are are still smarting over the major version change breaking everything and the need for complicated environments.

"heavy". It's 2024. We have gigabytes of storage on handheld phones. I don't buy it.

I work at scale - deploying scripts to hundreds of linux machines and any package you install will be multiplied that many times on the backend storage. You don't get the luxury of installing anything that isn't essential.

Ohhh, you work at scale do you? With... "hundreds" of Linux servers? And 50MB, which is basically a rounding error for most storage solutions, will break your bank? Sure Jan.

Last I checked, the JVM was larger than the standard Perl and Python interpreters, and had a much worse startup time (which is bad for short scripts).

Sorry - what potato from the '90s are you running software on these days?

Dude, I've worked with all these interpreters. The JVM's startup is slow, although there's been some improvement since the version 1.1 that I started out with. The interpreter speed is quite good once it gets going, so it remains a good choice for long-running or interactive programs where the startup is insignificant as a fraction of total program run-time, but if you're running a script that takes only a fraction of a second to execute, the JVM's startup can lengthen the time by an order of magnitude or more. Horses for courses and all that—I wouldn't write a complex interactive GUI program in Perl, either.

Perl would be my candidate for more advanced text handling than what sh can do.

Never used Lua but I think it's fun.

If nothing else works, just learn C/Rust. There's plenty of that on Linux systems, I think you'll be able to manage. Yes, it doesn't meet a lot of your requirements.

Quickly came to write "AWK!!!!!!!!!" but yeah... you don't want its superiority... 😜

You could use Ansible for automation just keep in mind it needs python.

perl might be on all your systems. It’s kind-of a legacy, but still actively developed. It’s not a great language: it looks like bash scripting on steroids. But if you just need to write some small scripts with a language more powerful than awk or bash, it does the job. If perl isn’t on all of your systems already, then I would choose a better scripting language.

TBH I don't even use awk that much, even that is plenty powerful for my needs. Perl absolutely blows my mind with how needlessly complex I can make stuff with it

Everyone always dunkin' on Perl, but I can't even tell you how often it's been the best tool for the job. Like, at least 3

Bro seriously just slap pyenv + pyenv-virtualenv on your systems and you’re good to go. They’re absolutely trivial to install. Iirc the latter is not a thing in windows, but if you’re stuck on windows for some reason and doing any serious scripting, you should be using WSL anyways.

Why does it need to be a scripting (by this I assume interpreted) language? For your requirements - particularly lightweight distribution - a precompiled binary seems more appropriate. Maybe look into Go, which is a pretty simple language that can be easily compiled to native binaries.

It is possible to wrap something like python into a single file, which is extracted (using standard shell tools) into a tmpdir at runtime.

You might also consider languages that can compile to static binaries - something like nim (python like syntax), although you could also make use of nimscript. Imagine nimscript as your own extensible interpreter.

Similarly, golang has some extensible scripting languages like https://github.com/traefik/yaegi - go has the advantage of easy cross compiling if you need to support different machine architectures.

@gomp Small footprint? Why not try forth. https://forth-standard.org/

I fear I am not enough reverse (or Polish, for that matter) :)

Anyway, I have great esteem for you (if you actually use forth and are not just trolling)

@gomp Well no I know someone who does forth, not me really. Perhaps forth is just too low-level for anything except hardware drivers and so.

Looking through the packages available for OpenWRT I would suggest Tcl, Lua, Erlang or Scheme (the latter is available through the Chicken interpreter). Try them out, see what you like.

Not sure how big node footprint is but would fit the bill. Would only recommend if you wanna go into web dev career in the future tho 🙃

vlang might fit your request pretty nicely. It's a bit patchy in places but mainly stable and gets pretty frequent updates

My go to for most of what you mention is Go, but that’s obviously a compiled language and not for scripting. Or is it - What do you think about https://github.com/traefik/yaegi, which provides an interpreter and REPL for Go? It would let you use a performant and well documented language in a more portable scripting way, but not preclude you from generating statically linked binaries if and when that’s convenient.

Powershell is the superior choice. But if you can't even have bash you probably won't have access.