Don't let your dreams be dreams

  $ wget 'https://github.com/BurntSushi/ripgrep/releases/download/14.1.1/ripgrep-14.1.1-x86_64-unknown-linux-musl.tar.gz'
  $ tar -xvf 'ripgrep-14.1.1-x86_64-unknown-linux-musl.tar.gz'
  $ ldd ripgrep-14.1.1-x86_64-unknown-linux-musl/rg
  ldd (0x7f1dcb927000)
  $ file ripgrep-14.1.1-x86_64-unknown-linux-musl/rg
  ripgrep-14.1.1-x86_64-unknown-linux-musl/rg: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, stripped

Sure, but Rust specifically uses static linking for everything but the very basics (ie. libc) in order to avoid the DLL hell.

Yes but I've never had a native tool fail on a missing libc. I've had several Python tools and JS tools fail on missing the right version of their interpreter. Even on the right interpreter version Python tools frequently shit the bed because they're so fragile.

I statically link all my Linux CLI tools against musl for this reason. Or use Nix.

That’s the first rule anyone writing portable binaries learns. Compile against an old libc, and stuff tends to just work.

> The worst is compiling a C program with a compiler that uses a more recent libc than is installed on the installation host.

This is only a problem, when the program USES a symbol that was only introduced in the newer libc. In other words, when the program made a choice to deliberately need that newer symbol.

You do you, obviously, but "now let npm work its wicked way" is an offputting step for some of us when narrowing down which tool to use.

My most comfortable tool is Java, but I'm not going to persuade most of the HN crowd to install a JVM unless the software I'm offering is unbearably compelling.

Internal to work? Yeah, Java's going to be an easy sell.

I don't think OP necessarily meant it as a political statement.

That's fine, I'll be avoiding using them :)

Opencode is a great model agnostic alternative which does not require a separate runtime

That's terrible, but at the very least there's the tiny justification that those are web API clients rather than standalone/local tools.

Shell scripts are a byproduct of the shell existing. Generations of programmers have cut their teeth in CLI environments. Anything that made shell scripts "no longer a thing" would necessarily destroy the interactive environment, and sounds like a ladder-pull to the curiosity of future generations.

> I think this world would be a better place if starting tomorrow shell scripts were no longer a thing.

Pretty much agreed - once any sort of complicated logic enters a shell script it's probably better off written in C/Rust/Go or something akin to that.

I'm just making an opinionated suggestion for the case when you're shipping a tool to end users and you don't want the tool to suck. Attaching a python or nodejs runtime to your tool is a quick way to make it suck for end users. It's laziness on the dev's part who didn't bother learning a better tool for the job.