Comment by never_inline

5 months ago

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.

7 comments

never_inline

Reply
bbkane  5 months ago

I also don't think there's a specification written for the jq query language, unlike 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/740663eeeb5e87c9225fb627... )

  • crabique  5 months ago

    There's https://github.com/itchyny/gojq which is pretty popular, even GitHub CLI embeds it for their --jq filter.

    • mdaniel  5 months 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 (MIT) because it actually strives to be an implementation of the specification versus just "execute better" as gojq does

BoingBoomTschak  5 months 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-li... https://world-playground-deceit.net/blog/2025/03/speeding-up...)

  • mdaniel  5 months 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  5 months 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).