from Hacker News

Gojq: Pure Go Implementation of Jq

by laqq3 on 8/21/22, 6:05 PM with 74 comments

  • by simonw on 8/21/22, 7:52 PM

    "gojq does not keep the order of object keys" is a bit disappointing.

    I care about key order purely for cosmetic reasons: when I'm designing JSON APIs I like to put things like the "id" key first in an object layout, and when I'm manipulating JSON using jq or similar I like to maintain those aesthetic choices.

    I know it's bad to write code that depends on key order, but it's important to me as a way of keeping JSON as human-readable as possible.

    After all, human readability is one of the big benefits of JSON over various other binary formats.

  • by fwip on 8/21/22, 7:53 PM

    Not implementing key-sorting is a curious decision:

    > gojq does not keep the order of object keys. I understand this might cause problems for some scripts but basically, we should not rely on the order of object keys. Due to this limitation, gojq does not have keys_unsorted function and --sort-keys (-S) option. I would implement when ordered map is implemented in the standard library of Go but I'm less motivated.

    I feel like --sort-keys is most useful when it is producing output for tools that do not understand JSON - for example, generating diffs or hashes of the JSON string. There is value in the output formatting being deterministic for a given input.

  • by lapser on 8/21/22, 8:59 PM

    I have actually fully replaced my jq installation with gojq (including an `ln -s gojq jq`) for a few years, and no script has broken so far. I'm super impressed by the jq compatibility.

    If you are going down this route, do be careful with performance. I don't know which is more performant as I've never really had to work with large data sets, but I can't help but feel jq will be faster than gojq in such case. I have no benchmarks backing this up, but who knows, maybe someone will benchmark both.

    One of my favourite features is the fact that error messages are actually legible, unlike jq.

  • by edsiper2 on 8/22/22, 12:28 AM

    Naming is hard, but please, do not repeat the mistake of many OSS project in the last 20 years calling each project by prefixing the name with the stack/environment involved.

    Now a "trending" language can catch the attention, but tomorrow?.. maybe. So the value proposition and starting from it name should be different (if you want adoption).

    For my use case, for a rewrite of jq I would expect one thing only: higher performance... show the numbers ;)

  • by cube2222 on 8/21/22, 9:11 PM

    This looks quite cool! I'm not sure though why I would use this over the original jq. However, I can definitely see the value in embedding this into my own applications, to provide jq scripting inside of them.

    Shameless plug: As I'm not a fan of the jq syntax, I've created jql[0] as an alternative to it. It's also written in Go and presents a lispy continuation-based query language (it sounds much scarier than it really is!). This way it has much less special syntax than jq and is - at least to me - much easier to compose for common day-to-day JSON manipulation (which is the use case it has been created for; there are definitely many features of jq that aren't covered by it).

    It might seem dead, as it hasn't seen any commit in ages, but to me it's just finished, I still use it regularly instead of jq on my local dev machine. Check it out if you're not a fan of the jq syntax.

    [0]: https://github.com/cube2222/jql

  • by spullara on 8/21/22, 9:59 PM

    i neither know nor care what language the original jq was implemented in.
  • by okasaki on 8/22/22, 8:50 AM

    Why use a special syntax that's hard to remember when you can just use Python?

    I wrote a jq-like that accepts Python syntax called pq: https://github.com/dvolk/pq

    So you can write stuff like:

        $ echo '{ "US": 3, "China": 12, "UK": 1 }' | pq -c "sum(data.values())"
        16
  • by jbirer on 8/22/22, 7:17 PM

    Go is not the choice I would make when writing a parser for JSON, good luck though.
  • by honkler on 8/22/22, 12:01 AM

    why?