g947o 4 days ago

I don't know Ruby, but chances are that your Python/JavaScript scripts are going to run in 5 years as well, if you stick to standard library.

  • dmix 4 days ago

    Just don't use any NPM libraries (if possible) and you'll be fine. I personally wouldn't use typescript for this sort of thing.

    • sroussey 4 days ago

      Why not? You can have bun or even node these days run it directly.

      • dmix 4 days ago

        I've been using node for a decade now and I've had to update NPM libraries a number of times as Node itself upgraded. I have a feeling it will get a lot more stable with ESM and the maturity of the language but if you're writing something you need to run 5-10yrs from now I wouldn't touch a library unless it's simple and has few of it's own dependencies.

        • skybrian 3 days ago

          Deno has used ESM from the beginning and it’s required on jsr.io. I agree about avoiding dependencies, but maybe it’s okay if they’re locked to a specific version.

pzmarzly 4 days ago

Fair. My bash scripts only broke 3 times over the years:

- when ls started quoting filenames with spaces (add -N)

- when perl stopped being installed by default in CentOS and AlmaLinux (had to add dnf install -y perl)

- when egrep alias disappeared (use grep -E)

norir 4 days ago

I consider luajit a much better choice than bash if both maintainability and longterm stability are valued. It compiles from source in about 5 seconds on a seven year old laptop and only uses c99, which I expect to last basically indefinitely.

greener_grass 4 days ago

Bash is not a great cross-platform choice. Too many subtle differences.

The best way is a scripting language with locked-down dependency spec inside the script. Weirdly .NET is leading the way here.

  • goalieca 4 days ago

    Stick to posix shell and it will run anywhere and on anything no matter how old.

  • Imustaskforhelp 4 days ago

    Python with uv seems decent in here too.

    • kh_hk 4 days ago

      python does EOL releases after 5 years. I guess versions are readily available for downloading and running with uv, but at that point you are on your own.

      bash is glue and for me, glue code must survive the passage of time. The moment you use a high-level language for glue code it stops being glue code.

  • tracker1 3 days ago

    Hard disagree... I find that Deno shebangs and using fixed version dependencies to be REALLY reliable... I mean Deno 3 may come along and some internals may break, but that should have really limited side effects.

    Aside: I am somewhat disappointed that the @std guys don't (re)implement some of the bits that are part of Deno or node compatibility in a consistent way, as it would/could/should be more stable over time.

    I like Deno/TS slightly more because my package/library and version can be called directly in the script I'm executing, not a separate .csproj file.

  • oguz-ismail2 4 days ago

    >Too many subtle differences.

    Such as?

    • greener_grass 4 days ago

      The tools you will call from your bash script differ in subtle ways between Linux, macOS, MinGW.

      One good example is `uuidgen`

      • oguz-ismail2 4 days ago

        >uuidgen

        That's neither a standard CLI utility nor a bash builtin.

        • greener_grass 3 days ago

          Technically maybe, I don't know. But in practice, your bash will use tools like this and break if they are different / missing on a future build host.

          If using a programming language with locked-down package dependencies, then all you need is the compiler/interpreter and your script will work.

gf000 4 days ago

For some quality of "run", because I'm hella sure that it has quite a few serious bugs no matter what, starting from escapes or just a folder being empty/having files unlike when it was written, causing it to break in a completely unintelligible way.

  • kh_hk 4 days ago

    I guess we have wildly different expectatives of what a language is responsible for and what not.

  • [removed] 4 days ago
    [deleted]