by laqq3 on 8/21/22, 6:05 PM with 74 comments
by simonw on 8/21/22, 7:52 PM
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
> 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
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
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
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.
by spullara on 8/21/22, 9:59 PM
by okasaki on 8/22/22, 8:50 AM
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())"
16by jbirer on 8/22/22, 7:17 PM
by honkler on 8/22/22, 12:01 AM