I love Rust (and Go seems fine), but what is the advantage of writing a CLI in either of these languages over Python?
Objectively, interpreted languages use less programmer time. The reason we use compiled languages is trading programmer time for performance, which is almost never the issue in CLIs.
Writing your devops scripting in Rust seems particularly unreasonable. Rust is a fantastic language, but Rust programmers are rare and expensive, Rust has nowhere near the ecosystem of packages, but more, the development cycle in Rust is simply much slower.
I used bash for years, but when I could dump it for a language with proper data types, modularization, and a huge ecosystem of productionized libraries that I can use and depend on in a formal, repeatable fashion, I mostly left it overnight and never looked back.
It's not just that my productivity was better, but I was able to write more reliable programs with more functionality that were more easily maintained by more programmers in less time.
You know, if it were up to me, we might all be writing in Lisp. But my preferences are fairly low on my priority list.
I am hoping always that I can write each program well enough that it can be given to a junior programmer to maintain and develop. Writing in Python and adding unit tests is the best and fastest way for me to do that.
I was very happy in my last job when I got a bug reported against some part of my CLI I thought no one had been using and it turned out it had seen heavy use, and it was just that no one had had to ask me any questions, at least partly because even the JS people could understand Python well.
---
Oh, and out of curiosity I looked at the last commit I did that was devops-y, quite a while ago now.
It read an existing Yaml config file, did some simple computations on some JSON logging data, and then rewrote the YAML file with changed data.
This was a half page of Python, and it took me less than an hour. I did not write a test because it was too short and obvious.
I know how I would have done that in Bash, with yq, and then convert the extracted tables from JSON with sed into something I could pass to some sort of statistical program, and run yq again to write out the results.
It would have taken me much more work. I would have had to re-learn yq's weird language. There would be one or perhaps two new binary dependencies, yq and whatever the program was that did the small, boring stats calculation.
And not one other person on the project would have had any understanding of it. I might have been the only person there who had ever used sed.
You shouldn't try to express yourself by being different, in programming. You should express yourself by writing boring but very clear code that is easy for everyone to understand and maintain and test. In 2023, Python is the most boring language, and also comes with a huge ecosystem for almost every purpose.
---
I'm going to end off with a story of how using Bash instead of Python allowed me to nearly halve the processing time of a script from over 20 hours to just over 11.
A datastore dumped databases as text, checksummed them, then compressed them, and finally uploaded them.
With a tiny call-out to bash, I was able to tee the checksumming and compression so they happened in parallel, and save most of a day.
(I would have liked to have also piped the output of the compression directly into the upload and save more time, but the AWS uploading system failed about half the time when we piped into it, and I didn't have bandwidth to track it down.)
I like bash fine. I like doing predictable, boring, reliable, tested engineering a lot better.
Thanks for reading and responding!
