If it is for myself: murex (my own DevOps focused shell: https://murex.rocks)

If it is for work: either Bash or whatever that companies preferred software development language (over the last ~20 years that's included: Pascal, Visual Basic, PL/SQL, Perl, PHP, Python, Typescript and others I've likely forgotten. Different companies will have different preferences)

If performance matters then these days Go is my "goto" language because it's a good compromise in terms of developer productivity and application performance. But I've used Java, C and C++ too. Depending on the particular problem I'm trying to solve.

...and if you ask me again in 5 years then the answer will be completely different again.

The sort answer is: there's no such thing as a single answer. Everyone will have their own preferences and business requirements.

Some context to my statements: I'm a SWE that works on infrastructure services and tooling, primarily on Linux but also Unixes.

It depends on what I'm doing but usually Go if an application requires any longevity at all.

I use Python or Java for things that require more dynamic typing. The main usecase here is big data or to prototype applications.

Bash I usually reserve for very small tasks. When I bootstrap services in containers, you'll usually find some Bash. A whole CLI written in Bash? I would not approve that PR. Bash lacks variable scoping for the most part, the ways in which you can implement it are hacky and non-obvious. Bash's syntax and the way it behaves varies by system, even installer scripts have to account for this. As I'm typing this, I realize the Bash code I write generally follows the same testing and constraints as the Makefiles I write.

I don't think I really understand the requirement for "a single document". This departs from programming practices I've built up over the years. When I come across large multi-thousand LOC documents (in any language, much less Bash) I'm usually concerned.

About the requirements and "single document":

Those tasks that I use bash for are usually one-offs, and live on the server they are used on.

Thus, it should be easy for the next admin/Dev to find it and understand/fix/extend it.

Of course, if there is a more advanced task those requirements fall short and there should be a proper Dev env with source control, tests, etc.

Ah, makes total sense. I was conflating the single document requirement with the original post which was seemingly trying to build a CLI tool.

python.

Which python? 2.7 that is symlinked to `python` on the distro? 3.5 that is installed by default? or perhaps you meant 3.9 but what about that cool library that you're gonna use which is only available for 3.9.2 and not 3.9.1 due to a bug?

How are you gonna handle installing that beautifulsoup dependency in a way that does not bork the OS python deps?

Are you gonna use `python -m venv` or `poetry` or `pipenv`?

perl

Not my cuppa, but I'd take it over bash any day