[okennedy]

Bash is ubiquitous and stable, making bash scripts incredibly portable.

All of the other languages you bring up are great for authoring code, but have a non-zero amount of friction when running code in the wild. Python may be omnipresent, but you can rarely count on a specific version or the presence of specific libraries. Go requires compiling platform-specific binaries. Even JVM- or JS-based software requires installing a separate toolchain first.

If you want to write some code (e.g., a launcher, installer, utility code, etc...) that is almost certainly going to run on any computing device created in the last several decades, bash is your language.

[ModernMech]

Why doesn’t Amber have equivalent issues? Such as depending on a specific version of bash, or specific executables to be installed.

Also does bash run on windows outside of WSL? Amber seems to argue that it doesn’t support Windows because Windows doesn’t support bash.

That would cut against the idea that bash can target more devices than Python, which runs natively on all platforms.

[Sebb767]

> Why doesn’t Amber have equivalent issues? Such as depending on a specific version of bash, or specific executables to be installed.

Because it's easy (for most cases) to write backwards-compatible or portable shell scripts and, since Amber is compiled, it can simply generate backwards-compatible code.

> That would cut against the idea that bash can target more devices than Python, which runs natively on all platforms.

The point is that Bash is more ubiquitously available, which is important if you write something like an install script.

[sundarurfriend]

> Also does bash run on windows outside of WSL?

Git Bash is pretty ubiquitous on developer machines in my experience.

[freedomben]

Amber doesn't have equivalent issues because bash and the utilities it uses like bc and sed are incredibly stable. I've found nontrivial shell scripts I wrote decades ago that still run entirely unchanged.

[bogwog]

I didn't realize we were going so far back. In that case, Perl may be more convenient than Python/Go, and almost certainly a better choice than bash.

Still,

> If you want to write some code (e.g., a launcher, installer, utility code, etc...) that is almost certainly going to run on any computing device created in the last several decades, bash is your language.

Can you give an example of a "several decades" old device for which you'd want/need to write a launcher or installer?

[hedora]

A few days ago, I tried running some code that hasn't been updated in about 5 years. The python launcher has bit-rotted, so now I need to rewrite it. The other 99% of the project compiles fine.

Things like perl (without CPAN) and bash generally take backward compatibility more seriously than python does.

My experience with python (even ignoring the 2 to 3 debacle) is that you can run code on machines that were setup +/- six months from when the software was written. That's unacceptable for non-throwaway use cases unless your company is willing to burn engineering time needlessly churning software that's feature complete and otherwise stable.

[rewgs]

But whenever people talk about writing Bash, you always have someone advocating that you should write POSIX sh instead if you want maximum portability. To paraphrase Qui-Gon Jinn, "there's always a more portable language."

Underlying all of these discussions is an attempt to reduce issues of portability to 0. It's a good goal, but IMO interpreted languages will by-definition never be the solution.

I've started reaching for Go in situations in which I'd usually reach for Bash or Python, and it's a godsend, because I can control for portability at compile time. If you make compiling for various GOOS and GOARCH targets the norm, portability is never an issue again.