I would welcome POSIX shell or at least bash as an alternative to a compiled C/Rust/Go binary.

But yeah, for these types of utilities, relying on an external language runtime like Python/Node is pretty rough.

Agreed but I would change it with "any compiled language that has no external runtime" and common shared libs dependencies. I don't care that a utility is written in Go, Zig, C++ or Pascal ;)

`jc` is available today as a compiled binary with all dependencies self-contained. The binaries and OS package installers are available under the GitHub Releases:

https://github.com/kellyjonbrazil/jc/releases

This is still python under the hood and not as small of a binary as I would like, but it does work.

But python is also universal? You can just bundle jc inside https://github.com/jart/cosmopolitan/tree/master/third_party... and it's as universal as it gets.

Replace C with Rust.

on embedded rust is still much larger than c because rust links its stdlib statically.

There is such a thing as no-stdlib Rust deployments.

which is for MCUs only and is like a bare metal language without any libraries, its use is very limited.

all I need is that rust's stdlib can be linked dynamically just like c/c++/java/whatever, if that happens I'm ready to switch to it.

It seems like you have multiple binaries (otherwise, I don't see how you would save space) in a context without an operating system, but do have abstractions like a linker; throwing this out there, you may be able to sort of fake having dynamically linked binaries with transparent disk compression. The shared code gets compressed, and you trade the overhead of your linker for the overhead of your compression, and probably roughly break even.

nope,not even close,the final size of a few binaries is at least 10x larger

Seems to me like anywhere Python is too bulky to work, a layer serializing and deserializing JSON at every pipeline step is likely to exhaust your memory too.