Gojq: Pure Go Implementation of Jq

&quot;gojq does not keep the order of object keys&quot; is a bit disappointing.<p>I care about key order purely for cosmetic reasons: when I&#x27;m designing JSON APIs I like to put things like the &quot;id&quot; key first in an object layout, and when I&#x27;m manipulating JSON using jq or similar I like to maintain those aesthetic choices.<p>I know it&#x27;s bad to write code that depends on key order, but it&#x27;s important to me as a way of keeping JSON as human-readable as possible.<p>After all, human readability is one of the big benefits of JSON over various other binary formats.

Not implementing key-sorting is a curious decision:<p>&gt; 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&#x27;m less motivated.<p>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.

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&#x27;m super impressed by the jq compatibility.<p>If you are going down this route, do be careful with performance. I don&#x27;t know which is more performant as I&#x27;ve never really had to work with large data sets, but I can&#x27;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.<p>One of my favourite features is the fact that error messages are actually legible, unlike jq.

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&#x2F;environment involved.<p>Now a &quot;trending&quot; language can catch the attention, but tomorrow?.. maybe. So the value proposition and starting from it name should be different (if you want adoption).<p>For my use case, for a rewrite of jq I would expect one thing only: higher performance... show the numbers ;)

This looks quite cool! I&#x27;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.<p>Shameless plug: As I&#x27;m not a fan of the jq syntax, I&#x27;ve created jql[0] as an alternative to it. It&#x27;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&#x27;t covered by it).<p>It might seem dead, as it hasn&#x27;t seen any commit in ages, but to me it&#x27;s just finished, I still use it regularly instead of jq on my local dev machine. Check it out if you&#x27;re not a fan of the jq syntax.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;cube2222&#x2F;jql" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cube2222&#x2F;jql</a>

i neither know nor care what language the original jq was implemented in.

Why use a special syntax that&#x27;s hard to remember when you can just use Python?<p>I wrote a jq-like that accepts Python syntax called pq: <a href="https:&#x2F;&#x2F;github.com&#x2F;dvolk&#x2F;pq" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dvolk&#x2F;pq</a><p>So you can write stuff like:<p><pre><code> $ echo &#x27;{ &quot;US&quot;: 3, &quot;China&quot;: 12, &quot;UK&quot;: 1 }&#x27; | pq -c &quot;sum(data.values())&quot; 16</code></pre>

Go is not the choice I would make when writing a parser for JSON, good luck though.

why?