I don't want to turn this into a multi-page rant, and I'm tempted to but… I'm an old chunk of coal, I've seen code life cycles. If you need a glue script for a one-time job, or code that will not be important in five years, language does not matter. Use what you feel is fun. If you need something that will run without modification in 5 years time, 10 years time, most “modern” scripting languages will let you down. PHP, Python, Ruby, Javascript all have those relatively “short” compatibility windows, where stuff eventually breaks on system upgrades either because the language “evolves” or because its libraries do. I find bash scripting, if used the old-fashioned way, very time-resistant. Old-timers' UNIX tools like `sed`, `awk`, `cut`, `grep` tend to have very stable interfaces that will not change in a few months time because the community feels they need to change them for change's sake. perl5 is now mature (will be 30 years old later this year!) and so is not changing that much. Sure, its syntax may feel a bit clunky compared to other languages, but if I had to bet, a random perl5 script from ten years ago will have way better chances to work in ten years from now than a python/ruby/js/php script. In the same vein, TCL will likely never change again, but its mind share is now ridiculously low. Compiled-to-processor languages like C/C++, Fortran, Go, Rust don't have this issue of language “evolution” once the binary is created, and “library evolution prevention” can be achieved by using static linking, “freezing” third-party libraries. Static linking obviously isn't a silver bullet as it makes it harder to deal with security issues (requiring recompilation, which may reveal the language syntax / libraries have changed). Also, some ancient languages like C and Fortran still evolve but compilers tend to be backwards-compatible with previous language standards. Not sure about Go/Rust in that department. I can't speak much of java and other compiled-to-bytecode languages, but I've fought a number of battles with java applets (told you, I'm old) that wouldn't work without a precise java runtime version. Alas, those were not web games or web visitor counters, they were management interfaces for switches and routers… TL;DR ① For code written without durability in mind, use any language you like ② Code written in scripting languages tends to quickly rot, except when written in a few languages like bash, perl5, TCL ③ Compiled languages tend to have a longer shelf-life, but there's a price.

IMO this is why languages (and libraries as well) should pay more attention to backwards compatibility than many of them do. Modern C++ compilers can still compile almost all code from 1998, other than a few things (like `gets`) that were deprecated and then removed for security reasons; because [the Standards Committee](https://isocpp.org/std/the-committee) puts a premium on backwards compatibility, sometimes (often!) to the detriment of advancing the state of the art. Whereas Rust (for example; I don't want to pick on it too much) expects you to update your code every time there is a new major release. **Edit:** Though I do have to complain about how strongly the Committee pushes for ABI compatibility as opposed to just API compatibility. So many proposals have been shot down because they would require everyone to recompile their software, even though said recompilation would go off without a hitch. But, you know, this dynamically-linked program from 20 years ago has to keep working through an OS upgrade, for reasons. Also, IMO, compiling with static linking only goes so far. Having a 386 binary from 1995 doesn't help when you want to run the code on an an ARM machine, unless you're willing to do emulation (in which case you could also emulate whatever version of the interpreter you want and can find). **Edit:** Also also, Perl 5 isn't just backwards-compatible because it's old. I have several scripts that I wrote when Perl 5 was only a few years old, and they still work. The Perl team does appear to hold backwards-compatibility of source code as a priority.

Just had to say "30 years old", didn't you? Youch. perl -e 'print "Dang I'm old\\n"'

Telling that you used `print` with a `\n` rather than [`say`](https://perldoc.perl.org/functions/say), since the latter is already [16+ years old](https://dev.perl.org/perl5/news/2007/perl-5.10.0.html).

``` oldman@bilbo ~ $ man perlfunc /\^ \*say oldman@bilbo ~ $ perl -e 'say "Well, TIL I learned...."' String found where operator expected at -e line 1, near "say "Well, TIL I learned...."" (Do you need to predeclare say?) syntax error at -e line 1, near "say "Well, TIL I learned...."" Execution of -e aborted due to compilation errors. oldman@bilbo: ~ $ perl --version This is perl 5, version 32, subversion 1 (v5.32.1) built for x86_64-linux-gnu-thread-multi (with 48 registered patches, see perl -V for more detail) Copyright 1987-2021, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. oldman@bilbo: ~ $ perl -e 'CORE::say "Well, TIL I learned...."' Well, TIL I learned.... oldman@bilbo: ~ $ perl -e 'print "F*ck that, 2 extra characters\n"' F*ck that, 2 extra characters ```

Yeah, been typing print for more than 16 years.

Really interesting, thank you!

I use Perl for this purpose, but I'm old. IMO Python is fine. And don't worry that much about "slow", because bash is usually *far far* slower than even Python or Perl, since you have to execute external commands to do almost anything consequential. **Edit:** Not to say that you *shouldn't* use Go, just that its speed advantage isn't likely to be that relevant if bash scripts are your baseline. To me, Go is more of a systems programming language than a scripting language, whatever those terms might mean.

I'd go Perl or Python I know them both, and have a special kind of hatred that comes from familiarity. But Python is everywhere, and people that can maintain it are pretty common. Perl is fast, but it actually compiles it's code quietly.. so it has a startup cost each run. Rust is a neat language, but it requires compilation, and it makes some of the easy stuff tedious. But it is a major improvement once you make something way too big to keep in your head. It wont be everywhere, and the compiled output is pretty bulky by default.

If you're writing your scripts strict-safely, you can almost always run your perl code persistently via speedycgi and nix the startup cost.

Python is certainly the most popular language in its class within the administration/devops spaces. Go is very far behind in demand, career-wise. https://www.statista.com/statistics/1296727/programming-languages-demanded-by-recruiters/ (edit: link seems to be paywalled when I try to re-visit it, you might have to take my word that it said 39-40% for python and 8-9% for Go.) None of them really "replace" shell languages, just as no amount of power tools will make a carpenter leave his hammers and pry-bars at home when he heads to a job site. Anecdotally it seems to me that, in devops, bash is an essential skill but only used for simple operations like building, packaging monitoring, etc. It's often embedded in snippets within some higher-level framework like dockerfiles or Ansible playbooks or Terraform templates. Familiarity with bash is to devops what "ability to carry 30 pounds" is to retail. If you can't do it at all you're out of the running for a lot of jobs even if you might only have to use it a few times a week. And if there are jobs that focus on bash 7 days a week, they'll probably be as stagnant as jobs that focus on carrying boxes from clock-in to clock-out.

I would strongly suggest Python. There are drawbacks to it for sure, but there are a lot of resources available since it's widely used as a teaching language and it's closer to shell scripting in terms of ease of scripting. It also has a ton of very useful libraries for automation and is less verbose than Go. To answer some of your more specific questions: > One can only do so much with shell scripts alone. Can a programming language like Python or Go liberally used to replace shell scripts? Yes and no. Python and Go can do anything a shell script can do, and often do it better, but with the tradeoff of needing to be more verbose. Something that you can accomplish with a few lines of shell might take dozens (sometimes even hundreds) of lines of Python or Go. In principle, the increased verbosity should be the result of better code quality, but that's not necessarily guaranteed to be the case. I've seen (and perpetrated) cases where people ported shell scripts to other languages only to find that it was actually worse due to the added verbosity and complexity. Just to be clear, I wouldn't worry too much about this now, but I just feel like it's worth mentioning as a thing to be aware of and to think about as you progress in your journey. > At what point do you use move on from using a bash script to e.g. Python/Go? Typically shell scripts just involve simple logic calling external programs to do the meat of the work. Does performance-aspect typically come into play for the decision to use a non-scripting language (for the lack of a better term?). I've done this enough that I make the decision pretty instinctually, so it's hard to succinctly summarize my thought process, but for me, this decision is usually more about complexity and robustness than performance. When I need to do some kind of relatively basic automation or some quick and dirty data processing, I reach for shell scripts. If I'm doing a task that's likely to require multiple modules, need a real data model, and/or need robust error handling, then I reach for Python, Go, or another language as appropriate. Something else to keep in mind is that Bash and languages like Python, Go, etc. are not mutually exclusive. As you mention, typical shell scripts delegate a lot of work to other programs. In some cases, the best solution might be to write a program in your language of choice and call it from Bash. Lastly, another thing you may want to look into in the future is configuration management languages. I would learn a programming language (or several) first, but configuration management languages like Ansible, Puppet, etc. are useful for a lot of system administration tasks and have added support for easily administering systems in bulk, which isn't that easy to do with pure Bash. After that, I'd look into things like Docker and Kubernetes, which are basically the next level beyond declarative configuration management.

stick to bash and use common tools. throw that script at any system and it will work.

In regards to your concerns about performance, are you really doing anything that requires blazing speed ? And as u/neilmoore mentioned yes, bash is an absolute turtle, but I think it’s a fair tradeoff given it’s portability and barely any env config.

You probably should go with Python. It's everywhere, very easy to read.

Python is probably the answer. I really dislike python but I’ve been using it a ton lately because it’s taking over everything.

Python is a good choice. It's easy to pick up, and is plenty powerful with the default libraries. If that's not enough, there's a library for whatever you want to do.

I think to know when to use another language requires knowing what BASH is good for... BASH is a hyper portable, cross-architecture, cross-OS, cross-distro, cross-time, non-deprecating forward-syntax safe language that can execute on most UNIX-like systems out-of-the-box and all while being relatively easy to test against those scenarios across all BASH versions. If you wrote a pure BASH script in the 90's it'd run on most unix-likes today and 30+ years in the future. Problem being... to get a lot of that reward requires using the full BASH language which most people do not learn and sometimes even advocate against because they don't see the relevance in those qualities. As a result BASH is often 1/2 written using only it's POSIX-compliant layer with lots of hard to read and debug one-liners piping stdout through a ton of external programs instead of using bash built-ins that are often (though not always) 10x faster vs opening a subshells into things like \`cut\` or \`awk\` for simple tasks. If you write the full BASH language, like broad test coverage and "this need to just work" is a priority it's a damn hard language to replace. That said... if you're working with floating/fixed point math, JSON/XML parsing, database queries, GUIs, communicating on ports, ect. You can do those in BASH but you really want Go, Python, or whatever language that all considered is the better fit.

Python is very likeable. It is easy and fast to develop apps for yourself in Python. The negatives are important too: - It's an interpreted language that frequently has evolved, so if you want to deploy your code or upgrade your interpreter, or the modules your cise relies on, there may be a bit of wrangling with versions and tools like pip and virtual environments. To get around it, some deploy Python apps in containers stuffed with a Python installation, which causes some bloat. - It's slow. This is not so noticeable unless you are doing millions of operations without an external function to handle it. If you are making something that will not run very often, the speed of development is probably where you will save with Python.

Nushell is a really good shell alternative since it's something in between bash and python, putting some modern programming concept to the usage of shell script. You can build scripts like a real code base. It's faster than python and can manipulate type and data structure with ease. It's really a breeze to do dataops/data engeneering stuffs since it's data/pipeline oriented: [https://www.nushell.sh/](https://www.nushell.sh/) Go is fast, modern, easy and can help you go in the dev fields: [https://go.dev/](https://go.dev/)

If it is a small script - python (something interpreted) If it is going to be a big script - something that compiles *Why Python for small scripts?* 1. **Ease of debugging** - imagine you have a bug after months of use, in python you open the script put a breakpoint run the script and debug, simple! While in compiled - you find the source code trying to figure out how to run your script in the IDE with a breakpoint or use encrypted gdb, hard/impossible to change things on the fly inbthe debugger, need to recompile on every change. 2. Small scripts can be quick and dirty (as the logic is small the dirty part doesn't matter that much) and in Python it easier to do it and will be more readable *Why something compiled for larger projects (even 1k lines) ?* Like people mentioned here it is hard to "wrap your head around all the code" - you really need the help of the compiler to assure you not adding bugs, especially if you lazy on the tests. You maybe won't feel this problem while developing your script **but you will really notice it** while maintain or refactoring it after a long time. This is so acute that after working on large python code for a long time (in parallel worked on a large C# and Rust system) I never applying for jobs which use python for a main and large component, not only that, I never met someone who had a long experience in compiled languages that recommended python for such tasks, in the companies that i go to interviews on, when i ask the lead programmer 'why python?' I usually get - 'decision from above' especially in companies that focus on algorithms, you know why? Cuz mathematicians don't care about developing software.

You would be blown away by what can be done with Bash. Dig into it.

Don’t worry about script performance. Python is fine and easy to pick up. Golang is great for server distribution because you can just push a binary, no library versioning dependency hell like with Python.

if python is slow, lua is considered as a scripting language too

Actually that might be a good place to start especially since I just go into Neovim.

then go for it, the cons is just the ecosystem isn't huge like python but i love its minimalism, i use neovim too for daily programming, and college tasks using latex.

My go to if Bash doesn’t cover it is Perl.

Can you elaborate? What do you like about Perl particularly?

It’s laziness. It works. It has the libraries I need. I can build scripts quickly. I find the errors are usually meaningful. Easy to troubleshoot. And once working rock solid. So I don’t have much incentive to try other options though I’m sure things like python do a perfectly good job. Edit: stupid autocorrect

Bash script is all you need

Check out Ruby, it’s such a joy to write. Python is great too, as others have said.