I sort of see that, but at the same time why not just compile to python instead? I get that python can be less convenient syntactically for "scripting" type things, but if you're writing in what's effectively a DSL that gets transpiled for a different interpreter anyway...

I'm guessing because Bash is "more everywhere" than Python.

As slow as Python is, though, Bash is more slow. Much more slow.

It’s actually fork() that’s slow, rather than Bash itself.

If you were to write Python code that did a of its business logic by spawning new processes rather than using its core libraries (which are written in C) then you’d find Python would be just as slow too.

But the exact point of Bash and other shells is to make launching new processes easy. This is the point that people miss when they say “write it in a real programming language”. Shells solve an entirely different problem to other languages. And “real” programming languages suck at working with other executables in a quick and convenient way.

I am wondering why not take an existing language like python, and compile that to bash?

Also for this to be really unique and good it needs insanity like being able to avoid all external dependencies, or else idempotently installing them in ways that can not affect anything else externally, or even temporarily, in multiple crazy various environments including nix? my mind never shuts up

> I am wondering why not take an existing language like python, and compile that to bash?

You'll run into the Alternative Implementation Problem

https://pointersgonewild.com/2024/04/20/the-alternative-impl...

https://news.ycombinator.com/item?id=40337036 - 10 days ago, 84 comments

Relevant excerpt:

> You may read this and think that the key lesson of this post follows the old adage that “if you can’t beat them, join them”. In some ways, I suppose it does. What I want to say is that if you start a project to try and position yourself as an alternative but better implementation of something, you are likely to find yourself stuck in a spot where you’re always playing catch up and living in the shadow of the canonical implementation.

This concept doesn't exactly map 1:1, but gist seems correct. Who wants to program in a worse and very limited version of Python? Who's going to keep things up to date in e.g. Amber as Python continues to evolve? Not fun.

i guess the idea is that you can scp the output script to a machine that has only a minimal *nix install and run it there without having to install anything more. so bash, bc and sed but not python or ruby

That's an argument for POSIX sh, not bash.

that is definitely true! though i wonder whether bash is ubiquitous enough these days that it can serve as an acceptable "we can rely on this being there" shell.

There are lots of new shells around that does support everything you’re describing. Eg:

- nushell

- elvish (was featured on HN recently)

- powershell

- murex (disclaimer: I’m the author of that one)

Yeah. Sh needs to be abandoned. There's a million better alternatives, including those without such an asinine syntax.

If I’m going to install a tool to run my code, why would I pick any of these alternatives instead of going straight to a “real” programming language?

Most of the value in sh to me is that it’s ubiquitous. I write a script and the runtime is already available across most devices, operating systems, containers, and everywhere else without an extra steps.

Because a shell is also REPL for interacting with command line utilities. It solves a different problem to “real programming languages”.

This is a well-informed observation.

It's unfortunate Amber doesn't have a Map data type, pretty big limitation.

I can think of ways of doing it, e.g. something along the lines of:

* Set the constraint that all keys must be of type String

* Then abuse /dev/shm/.Amber/${pid}/${func}/<put keys and values in files somewhere under here>

One approach I've used for running arbitrary code, with arbitrary dependencies, without having to rely on much support from the host system, is to create an Arx file (a shell snippet followed by tar gz data, which is self-extracting/executing) using `nix bundle`. On one hand it feels like a "poor man's container image"; but it's better in some ways since it doesn't need any daemons, etc. to be running.

For example, we had an EC2 machine whose init would fetch and run a shell script from S3, which spun up a big JVM application. We started getting strange errors from deep inside the JVM, which seemed to be caused by some security update somewhere in the stack (either ours or Amazon's); but that machine image had evolved via snapshots of snapshots, etc. and was a pain to figure out what it was running, let alone update and manage it in a sane way. As a quick fix I bundled a known-good JVM into an Arx file (along with other dependencies like Bash, etc. since it's Nix, so I might as well!) and put that on S3 in place of the old shell script. That got the EC2 machines working again, without having to mess with the (already messy) image; we gained a more sensible way of specifying dependencies (via Nix); and, since we were now building an artifact, rather than slinging a raw script, we could do stuff like running Shellcheck on the code. This definition was also easy to re-use when we eventually switched it to ECS containers (just changing the `nix bundle` options).

I will make no claims or implications whatsoever that it's "production-ready", but a different strategy which could work is to use Awk (which is at least as omnipresent as bash) to bootstrap an interpreter for a richer scripting language: https://beyondloom.com/blog/lila.html