jq is to cloud and "Infrastructure as Code" software what grep and awk are to unix software. It's the glue that lets you combine the pieces into a system. It's an odd language though, and not that easy to master. Tutorials like this one are helpful and needed... Thanks, Tyler!
However, there are quite a few typos in the examples... even the very first one is missing a quote and won't parse if cut-and-pasted as is.
I used to use shell scripts and jq a lot, but got tired of my scripts growing into monstrous mudballs of Bash hackery.
I do my scripting mostly in Go now and it's much easier to structure my code and grow it over time. I sometimes use Python, but Go is more flexible for what I do. I can compile an exe and drop it onto a host and run it, without worrying about VM and library versioning (or in Bash's case, making sure jq is installed and all the Unix utils have compatible versions).
How’s go’s batteries-included story? I’ve got nigh-on 50k lines of Python2 that IT is about to boot. My choice is to port it to ... something. I was going to do Python3 but I’ve always thought that a memory-management-free systems-like language would’ve always been better.
There is not a language as batteries-included as Go, that I've found. The standard lib includes almost everything, including an excellent HTTP server and client (even an HTTP proxy), a test framework, JSON/XML/CSV libs, SQL driver, CLI parser, a template library, crypto, etc. The "go" command includes tooling like a package manager, unit test runner, code formatter, static analyzer, race condition checker, code coverage, profiler, cross-compiler, etc.
I don't know what you mean by "memory-management-free" though, Go is still a garbage collected language.
ymmv there but for what I'm looking for Go is usually more helpful than python straight out of the box, specifically because you don't have to reach for a third party library to make simple http requests, which is what I often end up using a scripting language for. I did just pick up argparse though and was very pleasantly surprised about how nice it is, go's `flags` module in the stdlib is unfortunately not quite as nice and is one of the things I reach for a third party library on. However, because it's pure go it still compiles down to a single binary which you can just scp around.
Go's error-oriented style makes it very painful to write long sequences of fallible operations, particularly if your organization has test coverage requirements. I'll write servers in Go all day long, but scripting is the last thing I'd use it for.
There is some unfortunate boilerplate involved for scripting, but the benefits dramatically outweight that minor annoyance, IMO. Also, as the script accretes complexity (which happens quite often for me), the disciplined error handling starts adding more value.
That's only one way to handle an error. The benefit is that it's explicit, not implicit, and it's a psychological nudge to ask yourself "oh yeah this could produce an error, how should I handle it?". I can scan code and see where all the errors occur and how that particular component intends for each to be handled.
And handling errors in concurrent code is consistent--still passed as values. Languages with implicit stack-unwinding exceptions have inconsistent ways to deal with the errors because, in concurrent programs, error handling doesn't end once the stack is unwound, because there are lots of concurrent stacks. You then usually catch the exception near the top of the stack and pass it to another stack...as a value.
So yes, there is some boilerplate involved in that. But as a codebase grows, I appreciate that the language encourages me and others to be intentional about how errors are handled, and also provides a consistent mechanism for handling them in concurrent code (concurrency is a big reason I use Go to begin with).
However, there are quite a few typos in the examples... even the very first one is missing a quote and won't parse if cut-and-pasted as is.