User odnoletkov[1] has solved several years’ worth of Advent of Code in jq:

https://github.com/odnoletkov/advent-of-code-jq

[1] https://news.ycombinator.com/user?id=odnoletkov

That is simultaneously impressive and insane. Respect.

The JSON expressions used by MySQL and the AWS command line tool (JMESpath) are extremely limited compared to jq.

So not only do we end up learning multiple JSON path variations, but most of them are nearly useless for anything but the simplest use cases.

I appreciate the intention of including JMESpath in awscli, but I quickly dropped it in favor of piping the JSON results to jq.

I have a similar complaint but I'd guess there are (at least) two problems standing in the way of awscli getting jq language support: a python impl of the language with a license that awscli tolerates, and awscli being (in general) very conservative about changes. There are innumerable open issues about quality of life improvements that are "thank you for your input" and I'd expect that change to be similarly ignored

Not to mention that JMESpath appears to be abandoned.

There is a fork (https://github.com/jmespath-community/jmespath.spec), but it seems unlikely to be used by the aws cli (https://github.com/aws/aws-cli/issues/7396). Although, for that matter jq is semi-abandoned itself.

> I wish MySQL and AWS could have figured out a way to adopt it, or a subset of it, rather than each using different ones.

For AWS CLI, you can just output unfiltered JSON and pipe the results through jq; the filtering is client-side anyway, so it’s not like you are losing anything doing external filtering vs. filtering within the AWS CLI.

There has been a jq written in jq here on the front page.

It's not just a Turing complete language, but a well designed one, too.