4 ms·

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

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).

loeg 4y ago
> "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.
- jerrysievert 4y ago
  > 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 ...
  - loeg 4y ago
    Marginally faster is better than marginally slower, at least. I agree the JSON use is probably more compelling than their ZNG thing.
    - jerrysievert 4y ago
      > I agree the JSON use is probably more compelling than their ZNG thing. considering how much data I can already get via json (or converted to json via other json related standards such as geojson), there doesn't seem to be much of a compelling case to use ZNG. I'd love to hear different though!
enriquto 4y ago
> "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.
p5a0u9l 4y ago
Yes, but fortunately, your efforts will pay dividends when parsing all the 'z*' boutique formats that it supports, zson, zst, zng, the list goes on. /s
- mattnibs 4y ago
  Not sure if this came across in the article, but all the "boutique" z* formats are all representations of the same zed model https://zed.brimdata.io/docs/formats/zed/ https://zed.brimdata.io/docs/formats/zed/

4 ms·

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

by algesten 4y ago

loeg 4y ago
> "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.
- jerrysievert 4y ago
  > 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 ...
  - loeg 4y ago
    Marginally faster is better than marginally slower, at least. I agree the JSON use is probably more compelling than their ZNG thing.
    - jerrysievert 4y ago
      > I agree the JSON use is probably more compelling than their ZNG thing. considering how much data I can already get via json (or converted to json via other json related standards such as geojson), there doesn't seem to be much of a compelling case to use ZNG. I'd love to hear different though!
enriquto 4y ago
> "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.
p5a0u9l 4y ago
Yes, but fortunately, your efforts will pay dividends when parsing all the 'z*' boutique formats that it supports, zson, zst, zng, the list goes on. /s
- mattnibs 4y ago
  Not sure if this came across in the article, but all the "boutique" z* formats are all representations of the same zed model https://zed.brimdata.io/docs/formats/zed/ https://zed.brimdata.io/docs/formats/zed/