Live data from Hacker News

Zq: An easier and faster alternative to jq

brimdata.io

11–20 of 237 posts

Re: Zq: An easier and faster alternative to jq

#12
jq is incredibly powerful and I'm using it more and more. Even better, there is a whole ecosystem of tools that are similar or work in conjunction with jq:

* jq (a great JSON-wrangling tool)

* jc (convert various tools’ output into JSON)

* jo (create JSON objects)

* yq (like jq, but for YAML)

* fq (like jq, but for binary)

* htmlq (like jq, but for HTML)

List shamelessly stolen from Julia Evans[1]. For live links see her page.

Just a few days ago I needed to quickly extract all JWT token expiration dates from a network capture. This is what I came up with:

    fq 'grep("Authorization: Bearer.*" ) | print' server.pcap | grep -o 'ey.*$' | sort | uniq | \
    jq -R '[split(".") | select(length > 0) | .[0],.[1] | gsub("-";"+") | gsub("_";"/") | @base64d | fromjson]' | \
   jq '.[1]' | jq '.exp' | xargs -n1 -I! date '+%Y-%m-%d %H:%M:%S' -d @! 
It's not a beauty but I find the fact that you can do it in one line, with proper parsing and no regex trickery, remarkable.

[1] https://jvns.ca/blog/2022/04/12/a-list-of-new-ish--command-l...

Re: Zq: An easier and faster alternative to jq

#13
post #7
post #3

I don't get it. "Instead of learning jq DSL, learn zq DSL". To me they look similarly complicated and the examples stresses certain aggregation operations that are harder to do in jq (due to it being stateless).

> "Instead of learning jq DSL, learn zq DSL" I think you got it — that’s exactly the idea. They claim (reasonably?) that it’s a more intuitive DSL; and it supports state. They also make some performance claims towards the end of the article.

> They also make some performance claims towards the end of the article.

essentially a marginal speed increase they think on json, but a much bigger speed increase (5x-100x they claim) if you switch to their native format ZNG.

if I'm switching formats completely, I'm not sure why I care about jq vs zq in json performance ...

Re: Zq: An easier and faster alternative to jq

#14
I would love to see what jq looks like on something like a 1mil line Json vs this. In my experience jq syntax is fine and I've not ran into a performance issue on any one file but I seem to see a jq clone every few months on here so someone seems to need that, or maybe it's just the new volume slider problem who knows.

Re: Zq: An easier and faster alternative to jq

#15
post #3

I don't get it. "Instead of learning jq DSL, learn zq DSL". To me they look similarly complicated and the examples stresses certain aggregation operations that are harder to do in jq (due to it being stateless).

> "Instead of learning jq DSL, learn zq DSL".

A saner approach is to gron the damn json and just use regular unix tools on the data.

Re: Zq: An easier and faster alternative to jq

#16
post #7

Earlier quoted context omitted.

> "Instead of learning jq DSL, learn zq DSL" I think you got it — that’s exactly the idea. They claim (reasonably?) that it’s a more intuitive DSL; and it supports state. They also make some performance claims towards the end of the article.

> They also make some performance claims towards the end of the article. essentially a marginal speed increase they think on json, but a much bigger speed increase (5x-100x they claim) if you switch to their native format ZNG. if I'm switching formats completely, I'm not sure why I care about jq vs zq in json performance ...

Marginally faster is better than marginally slower, at least. I agree the JSON use is probably more compelling than their ZNG thing.

Re: Zq: An easier and faster alternative to jq

#17

The name of its corporate progenitor may leave a bad taste in some mouths, but I highly recommend PowerShell for this sort of thing. It's cross platform, MIT licensed, and comes with excellent JSON parsing and querying capabilities. Reading, parsing, and querying JSON to return all red cars: Get-Content cars.json | ConvertFrom-Json | ? { $_.color -eq 'red' } The beauty of this is that the query syntax applies not jus…

> The beauty of this is that the query syntax applies not just to JSON but to every type of collection,

This is the best part of pwsh. Everything is standardized, you're not guessing at the idioms of each command, and you're working with objects instead of parsing strings!

My second favorite part is having access to the entire C# standard library.

Re: Zq: An easier and faster alternative to jq

#18

The name of its corporate progenitor may leave a bad taste in some mouths, but I highly recommend PowerShell for this sort of thing. It's cross platform, MIT licensed, and comes with excellent JSON parsing and querying capabilities. Reading, parsing, and querying JSON to return all red cars: Get-Content cars.json | ConvertFrom-Json | ? { $_.color -eq 'red' } The beauty of this is that the query syntax applies not jus…

PowerShell "sends basic telemetry data to Microsoft [...] about the host running PowerShell, and information about how PowerShell is used" [1].

And since it relies on .NET, that also requires its own separate opt-out for its telemetry. There might be other components, now or in the future, that also send data to Microsoft by default and would have to be separately discovered and disabled.

[1] https://docs.microsoft.com/en-us/powershell/module/microsoft...

Re: Zq: An easier and faster alternative to jq

#20
These guys must really hate functional programming.

I can see where jq might confuse someone new to it, but their replacement is irregular, stateful, still difficult, and I don't even see variable binding or anything.

jq requires you to understand that `hello|world` will run world for each hello, passing the world out values to either the next piped expression, the wrapping value-collecting list, or printing them to stdout.

it's a bit unintuitive if you come in thinking of them as regular pipelines, but it's a constant in the language that once learned always applies.

this zed thing has what appears to be a series of workarounds for its own awkwardness, where they kept tacking on new forms to try to bandaid those that came before.

additionally, since they made attribute selectors barewords where jq would require a preceding reference to a variable or the current value (.), I'm not sure where they'll go for variables should they add them.

Post reply on HN