Hacker News Reader

Java's "runtime needs" are a lot simpler than Python's - it's very easy to create a jar that works on any JVM back to 8 (which everyone has) or even earlier - although the language is unpleasantly verbose for ad-hoc scripting. (I work in Scala most of the time and write command line utilities in it too; the JVM startup is tedious but not worth the overhead of switching to a different language). Ruby also used to be a popular option in the sysadmin space; it's pretty similar to Python but hasn't shot itself in the foot quite as vigorously on the dependency management front.

Something like Swift might be a good option in the "OCaml featureset + boring syntax + low startup overhead" space, which is what we're really looking for.

I like scala a lot but it I think it gives too many options to people that can be abused to show "cleverness" which is the last thing you want in a utility program. I stick to Scala basics and it is wonderfully concise compared to Java.

Ah yes Swift is another excellent choice. I didnt like it much originally (few years ago) but based on an HN comment recently, went back to do the introductory tutorial. It has come a long way and is very pleasant to use. If I had to guess, its close association with Apple might bring "iOS"/"mac"-only connotations that might make folks not consider it. Don't know how I forgot about it.

Slight tangent: what’s the easiest Java runtime to setup? Is there a single binary JRE that’s fully open source? Edit: and not from Oracle?

This is just an idle question I’ve had, not related in any way to Python.

Generally, I'd use Eclipse Temurin from Adoptium, if I not already in a Linux distro that has a JRE package.

I use Deno for this. It's the only scripting system where you can actually have a single file script with no compilation needed and use third party libraries reliably.

You also get great static types which is nice.

Interesting! I knew F#, C#, and Elixir supported this scenario, but good to know Deno has this as well :)

Do F# and C# really support it? How do you specify dependencies from within the script?

Yeah! F# has native support[1] and C# can do it with a third-party tool[2]. For both, the syntax for referencing a third-party NuGet package inside the script is e.g.:

    #r "nuget: Newtonsoft.Json"

[1]: https://learn.microsoft.com/en-us/dotnet/fsharp/tools/fsharp... [2]: https://github.com/dotnet-script/dotnet-script

Very interesting, thanks for the info!

Deno is pretty nice for that. There are other systems that automatically satisfy dependencies for single-file scripts. I have gathered a list at https://dbohdan.com/scripts-with-dependencies. I am not sure about their individual reliability, because I have only written one example for most of them, but some are old, have users who rely on them for work, or both.

Great list! I tried a couple of these and found a big issue is IDE support - might be worth checking which ones have IDE support.

Also it seems like F# and C# should be on the list (see other comments in this thread).

Thanks!

It didn't cross my mind to add IDE information. (I don't use an IDE, which may be a mistake. I want to give IntelliJ IDEA a serious try.) I'll be honest: I probably won't add this information. Sorry. N projects × M IDEs is a sizable number of fields to keep accurate by hand, and I've learned this kind of maintenance is best avoided.

I have tried https://github.com/dotnet-script/dotnet-script. It seemed like it could not download dependencies when you ran the script, only reference already installed dependencies. At that point I stopped and did not add it to the list, since it would not qualify. I may have been wrong. I have a mental note to look at it again.

I'll see what F# does. It may work differently from how I understood dotnet-script to work. (It isn't the criterion for inclusion, but as someone who enjoyed writing Standard ML and not so much Haskell, I am actually interested in F#.)

Yeah fair enough. Based on my experience anything that's a third party tool won't have IDE support and is really a bit useless. Even Deno is slightly annoying because it obviously conflicts with the official Typescript IDE support, so at least in VSCode you have to enable it on a workspace-by-workspace basis. And I've had one project where I had "normal" NPM-based Typescript and a Deno script, and it just doesn't work.

F# support looks really interesting though; I'm definitely going to check it out.

I was wrong about dotnet-script: it does download dependencies. (Which makes more sense than the alternative. It would need a good reason to not copy this feature from F#.) I have added C# and F# to the list.

Haskell is useful to stop other people from breaking your scripts.

I find Ním super interesting and feel like it has a lot of potential. I wish it was more mainstream.

Nim is a strange choice to come to mind while there is Lua. Much more approachable and lightweight glue language for numerous C libs and tools existing on any os. If you go in that direction than D seems like a better choice that could also come to mind. Basically C but with gc. All these are good choices for system scripting any day.

I am not saying this as an expert but I needed to set an environment variable with lua and it's not supported. You can read but not write them.(There's getenv but no setenv - i just looked it up and it's due to Ansi C not having the latter) I believe it has something to do with cross platform compatibility. This is pretty basic stuff. Maybe it's just the standard library and people just import something for it.

I wish there was something elaborated for scripts that run on Node. I've been using nbb[1] for scripting, and although it all runs through Node.js, it is fast to start up and quick to prototype/debug scripts. The best part is in CI I can simply `npx nbb path/to/script.cljs`. Things get clunky if I want to use anything outside of the Node stdlib (or the few things that come out of the box, like tools.cli for command-line argument parsing) though, since then you need the dreaded node_modules folder around.

[1] https://github.com/babashka/nbb

Why is nbb or anything else necessary to run node scripts? Compared with a Python Node runtime does not come with all batteries included, but is rich enough to replace shell scripts. It even supports things like file system change notifiers, while Python requires external dependencies for that. So I run the scripts directly with node.

> Python is basically almost everywhere installed but the dependency on runtime + venv oddities bring their own set of problems

Not that it changes your core message, but if you need scripting dependencies, you should use pipx[0]. Pipx will manage isolated virtual environments for each utility. ‘pipx install black’ will create a dedicated venv just to hold black. Invoking ‘pipx upgrade-all’ will scan all venvs for out of date utilities.

[0] https://pypa.github.io/pipx/

True but then the script needs to install its dependencies dynamically from a given host and hosts may have different configurations/network restrictions etc. Also, that'll result in scripts having to include their install related boilerplate which is besides the core functionality OR we need a separate script/stage that sets it all up. Admittedly these are solved problems but it all just feels a bit more messy compared to, say, a Go utility which can be just dropped and run.

My personal rule of thumb is that if it requires something not in the Python standard library, it is no longer a script and requires a real development process.

Are Python dependencies are problem for scripting given that you'll almost certainly use only the standard library? What can bash do for which you need a third-party library in Python?

Argument parsing with argparse is a bit more tedious than click, and the "requests" dependency is very practical for HTTP requests. You could need a YAML parser...

I use PHP for administrative tasks on a server that runs wordpress and few other PHP apps.

My only reservation is that PHP API to start external processes are awkward. They either use a shell and require careful escaping of arguments or too low level with explicit fork/exec. I took care of that with few utilities, but for a quick replacement of shell scripts this is a significant drawback.

On the other hand modern PHP supports types out-of-the box. It turned out to be a big plus when those administrative scripts grew in size.

While it moves it from a single script to needing a composer.json and vendor directory, I find the Process component [1] has removed the footguns I used to encounter.

1. https://symfony.com/doc/current/components/process.html

Babashka[0] is also a nice option for scripting, if you're a Clojure/Lisp fan.

[0] https://babashka.org/