5 ms·

JQ is the most feature-rich of the bunch. It's defacto standard and I usually just default to it because it offers so much - assignment, various builtins such a

JQ is the most feature-rich of the bunch. It's defacto standard and I usually just default to it because it offers so much - assignment, various builtins such as base64 encoding. The disadvantage is that it's not easily embeddable in your own programs - so programs use JSONPath / Go templates often.

bbkane 1y ago
I also don't think there's a specification written for the jq query language, unlike https://jmespath.org/ https://jmespath.org/ , which as you mentioned also has more client libraries. I too am probably going to embed jmespath in my app.I need it to allow users to fill CLI flags from config files, and it'll replace my crappy homegrown version ( https://github.com/bbkane/warg/blob/740663eeeb5e87c9225fb62718c91c51a116ba13/config/jsonreader/jsonreader.go https://github.com/bbkane/warg/blob/740663eeeb5e87c9225fb627... )
- crabique 1y ago
  There's https://github.com/itchyny/gojq https://github.com/itchyny/gojq which is pretty popular, even GitHub CLI embeds it for their --jq filter.
  - mdaniel 1y ago
    gojq is also my favorite for two "day to day" reasons: - the error messages are night and day better than C-jq - the magick of $(gojq --yaml-input), although I deeply abhor that it is 10 characters longer than "-y" It's worth mentioning https://github.com/01mf02/jaq https://github.com/01mf02/jaq (MIT) because it actually strives to be an implementation of the specification versus just "execute better" as gojq does
- wwader 1y ago
  The jaq author is working on a formal specification of jq https://github.com/01mf02/jq-lang-spec https://github.com/01mf02/jq-lang-spec. I think it has also help that there are several implementations of jq now like, gojq, jaq and jqjq, that has helped finding edge cases and weird behaviours.
BoingBoomTschak 1y ago
And it's yet another terrible DSL that you must learn when it could have been a language everybody already knows, like Python. The query part isn't even that well done, compared to XPath/JSONPath. I said goodbye to it a few weeks ago, personally (https://world-playground-deceit.net/blog/2025/03/a-common-lisp-jq-replacement.html https://world-playground-deceit.net/blog/2025/03/a-common-li... https://world-playground-deceit.net/blog/2025/03/speeding-up-cljqalbum.html https://world-playground-deceit.net/blog/2025/03/speeding-up...)
- mdaniel 1y ago
  > And it's yet another terrible DSL that you must learn when it could have been a language everybody already knows, like Python. Oh, yeah, I 100% want to type this 15 times a day # I'll grant you the imports, in the spirit of fairness aws ec2 describe-instances | python -c ' for r in json.load(sys.stdin)["Reservations"]: print("\n".join(i["PrivateIpAddress"] for i in r["Instances"])) ' because that is undoubtedly better than aws ec2 describe-instances | jq -r '.Reservations[].Instances[].PrivateIpAddress' I mean, seriously, who can read that terrible DSL with all of its line noise > The query part isn't even that well done, compared to XPath/JSONPath. XPath I'll grant you, because it's actually very strong but putting JSONPath near jq in a "could be improved" debate tells me you're just not serious. JSONPath is a straight up farce
  - BoingBoomTschak 1y ago
    1) You realize the boilerplate of reading and serializing can be abstracted, right? 2) I didn't say "replace jq with Python", but that the language part (not the functions) of jq is horrible and didn't need to be invented. Same as Avisynth vs Vapoursynth. 3) I only mentioned Python as an example, I wouldn't choose a language that needs newlines in this specific case. For example, in my own case, this expression is `cljq '(? $ "Reservations" * "Instances" * "PrivateIpAddress")` and if I need to do more complicated stuff (map, filter, group, etc...), I use CL instead of a bespoke, ad-hoc DSL that I never remember. > JSONPath is a straight up farce Why? At least it's specified (though you might say that jq is too, through jaq).

bbkane 1y ago

I also don't think there's a specification written for the jq query language, unlike https://jmespath.org/ https://jmespath.org/ , which as you mentioned also has more client libraries. I too am probably going to embed jmespath in my app.I need it to allow users to fill CLI flags from config files, and it'll replace my crappy homegrown version ( https://github.com/bbkane/warg/blob/740663eeeb5e87c9225fb62718c91c51a116ba13/config/jsonreader/jsonreader.go https://github.com/bbkane/warg/blob/740663eeeb5e87c9225fb627... )

crabique 1y ago
There's https://github.com/itchyny/gojq https://github.com/itchyny/gojq which is pretty popular, even GitHub CLI embeds it for their --jq filter.
- mdaniel 1y ago
  gojq is also my favorite for two "day to day" reasons: - the error messages are night and day better than C-jq - the magick of $(gojq --yaml-input), although I deeply abhor that it is 10 characters longer than "-y" It's worth mentioning https://github.com/01mf02/jaq https://github.com/01mf02/jaq (MIT) because it actually strives to be an implementation of the specification versus just "execute better" as gojq does
wwader 1y ago
The jaq author is working on a formal specification of jq https://github.com/01mf02/jq-lang-spec https://github.com/01mf02/jq-lang-spec. I think it has also help that there are several implementations of jq now like, gojq, jaq and jqjq, that has helped finding edge cases and weird behaviours.

BoingBoomTschak 1y ago

And it's yet another terrible DSL that you must learn when it could have been a language everybody already knows, like Python. The query part isn't even that well done, compared to XPath/JSONPath. I said goodbye to it a few weeks ago, personally (https://world-playground-deceit.net/blog/2025/03/a-common-lisp-jq-replacement.html https://world-playground-deceit.net/blog/2025/03/a-common-li... https://world-playground-deceit.net/blog/2025/03/speeding-up-cljqalbum.html https://world-playground-deceit.net/blog/2025/03/speeding-up...)

mdaniel 1y ago
> And it's yet another terrible DSL that you must learn when it could have been a language everybody already knows, like Python. Oh, yeah, I 100% want to type this 15 times a day # I'll grant you the imports, in the spirit of fairness aws ec2 describe-instances | python -c ' for r in json.load(sys.stdin)["Reservations"]: print("\n".join(i["PrivateIpAddress"] for i in r["Instances"])) ' because that is undoubtedly better than aws ec2 describe-instances | jq -r '.Reservations[].Instances[].PrivateIpAddress' I mean, seriously, who can read that terrible DSL with all of its line noise > The query part isn't even that well done, compared to XPath/JSONPath. XPath I'll grant you, because it's actually very strong but putting JSONPath near jq in a "could be improved" debate tells me you're just not serious. JSONPath is a straight up farce
- BoingBoomTschak 1y ago
  1) You realize the boilerplate of reading and serializing can be abstracted, right? 2) I didn't say "replace jq with Python", but that the language part (not the functions) of jq is horrible and didn't need to be invented. Same as Avisynth vs Vapoursynth. 3) I only mentioned Python as an example, I wouldn't choose a language that needs newlines in this specific case. For example, in my own case, this expression is `cljq '(? $ "Reservations" * "Instances" * "PrivateIpAddress")` and if I need to do more complicated stuff (map, filter, group, etc...), I use CL instead of a bespoke, ad-hoc DSL that I never remember. > JSONPath is a straight up farce Why? At least it's specified (though you might say that jq is too, through jaq).