Live data from Hacker News

Zq: An easier and faster alternative to jq

brimdata.io

91–100 of 237 posts

Re: Zq: An easier and faster alternative to jq

#91

Whenever jq comes up I feel obligated to mention 'gron'[1]. If all you're doing is trying to grep some deeply nested field, it's way easier with gron, IMHO. [1] https://github.com/tomnomnom/gron

Used it only this morning to find out if/where the JSON for a tweet mentioned the verification status of the poster and/or retweetee[1]. Quick and easy to dump it through `gron | grep verif` to find out the paths.

[1] "the person who was retweeted" in lieu of a better word.

Re: Zq: An easier and faster alternative to jq

#92
post #6

Since no one seems to know about it, jq is described in great detail on the github wiki page [0]. That flattens the learning curve a lot. It's not as arcane as it seems. The touted claim that is fundamentally stateless is not true. jq is also stateful in the sense that it has variables. If you want, you can write regular procedural code this way. Some examples [1] The real problem of jq is that it is currently lackin…

I found it hard to approach at first, but I think it was just the lack of material that worked through simple examples step by step. I ended up writing my own guide to it, that in my unbiased opinion makes it easier to get the point where in-depth examples and language descriptions are easier to understand. Edit: Oh, wow, it's even mentioned in this article. Maybe I should read before commenting. https://earthly.dev/…

I discovered jq after I wrote my own (extremely limited) version of it. I need it quite often, and yet I've never managed to get up the activation energy to learn enough for it to be useful. I need to have some notion of the computation model before anything is going to make sense to me. I hate learning things in completely disparate pieces that I need to memorize in hopes that someday it will just click together and I'll derive the underlying principles.

Your guide was great for this. It stepped me through enough of the bare basics in a way that the underlying model was obvious. It didn't get me nearly far enough for many of the tasks that I need jq for, but it got me started and that's all I really needed. Everything additional that I need to learn becomes obvious in retrospect—"of course there's an operator for this, there kind of has to be!".

Thank you!

Re: Zq: An easier and faster alternative to jq

#93
post #81

Earlier quoted context omitted.

I conceptually like pwsh, but even as your example shows, I don't have the RSI budget left to spend on typing that extremely verbose expression every day jq and its unix-y friends allow me to trade off expressiveness against having to memorize arcane invocations

I hear that, I use and like *nix too. PowerShell aliases help a lot. It comes with some predefined, like `gc` for `Get-Content`. The above example could be rewritten: gc cars.json | ConvertFrom-Json | ? color -eq 'red' `ConvertFrom-Json` doesn't have a default alias, but you can define one in your PowerShell profile. I do that for commands I find myself using frequently. Say we pick convjson: gc cars.json | convjson…

You don't need $_ for immediate properties which looks much cleaner:

    gc cars.json | convjson | ? color -eq 'red'

Re: Zq: An easier and faster alternative to jq

#94
post #62

Earlier quoted context omitted.

I don’t agree. There is a great deal of room for improvement in jq performance. I profiled one invocation and it spent the majority of its time asserting that the stack depth was lower than some amount, which is crazy. I rebuilt it with NDEBUG defined and it was seriously ten times faster, but it’s not safe to run it that way because it has asserts with side effects, which is also crazy. Rewriting all or parts of it…

Fair point! I don't mean to say jq performance can't or shouldn't be improved. Just that jq does two things: 1) ingest and 2) query. If you're doing a bunch of exploration on a single dataset in one period of time or if the dataset is large enough and you're selecting subsets of it, you can ingest the data into a database (and optionally toggle indexes). Then you can query as many times as you want and not worry abou…

I have a large GeoJSON dataset I analyze to answer local government questions. It is of course loaded into a database for common questions but I also find myself doing ad hoc queries that aren’t suited to the database structure, and that’s where I find myself waiting for jq. Also I use jq as the ETL for that database.

Re: Zq: An easier and faster alternative to jq

#95
post #38
post #32

Earlier quoted context omitted.

I want to learn powershell, but I have an internal ick bias because I've been using bash for so many years. The tab behavior is the exact opposite of what I expect and it short circuits my brain every single time I press it. Having structured data in the pipes seems very useful and powerful though so I should probably just bite the bullet.

Tab behavior is configurable. I have mine set to menu expansion. Set-PSReadLineKeyHandler -Key Tab -Function MenuComplete

Thanks for that! I've recently been learning PowerShell. After 30 years of bash it is interesting.

Re: Zq: An easier and faster alternative to jq

#96
post #81

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…

I conceptually like pwsh, but even as your example shows, I don't have the RSI budget left to spend on typing that extremely verbose expression every day jq and its unix-y friends allow me to trade off expressiveness against having to memorize arcane invocations

[deleted]

Re: Zq: An easier and faster alternative to jq

#97
post #88

Earlier quoted context omitted.

> It's not as arcane as it seems. The issue with jq is that I use it maybe once a month, or even less. The syntax is "arcane enough" that I keep forgetting how to use it because I use it so sporadically. In comparison awk – which I also don't use that often – has a much easier syntax that I can mostly remember. Not entirely convinced by the zq syntax either though; it also seems "arcane enough" that I would keep forg…

Same issue. However, I do successfully rely on using ctrl-r a lot to search prior invoked commands. And have a few core aliases that I've cobbled together....

Here because.... I didn't know of ctrl-R. What a life changer (although I had an alias for "hg" to "history | grep" :) )

Re: Zq: An easier and faster alternative to jq

#98
Hi, all. Author here. Thanks for all the great feedback.

I've learned a lot from your comments and pointers.

The Zed project is broader than "a jq alternative" and my bad for trying out this initial positioning. I do know there are a lot of people out there who find jq really confusing, but it's clear if you become an expert, my arguments don't hold water.

We've had great feedback from many of our users who are really productive with the blend of search, analytics, and data discovery in the Zed language, and who find manipulating eclectic data in the ZNG format to be really easy.

Anyway, we'll write more about these other aspects of the Zed project in the coming weeks and months, and in the meantime, if you find any of this intriguing and want to kick the tires, feel free to hop on our slack with questions/feedback or file GitHub issues if you have ideas for improvements or find bugs.

Thanks a million!

https://github.com/brimdata/zed https://www.brimdata.io/join-slack/

Re: Zq: An easier and faster alternative to jq

#99
Okay, so I'm a big scripter and not much of a programmer and I definitely have found jq to be mostly worthless to me; but it also looks like zq doesn't much help?

Seems to me that if you're in a shell, then you should be "shell-like." There should not be much of a learning curve at all, and when in doubt, try to behave like other shell tools, in a Unix way way. Make pipe behavior generally predictable, especially for those who aren't deep into json et al.

And if you're not going to do that, say so on "the box?"

(Disclaimer, it could be that I'm an idiot when it comes to all of this and I'm missing something big. Kind of feels that way, and I welcome correction)

Re: Zq: An easier and faster alternative to jq

#100
"Easier" is subjective. For simple use-cases, zq is harder to understand than jq.

I also have never seen jq as a performance bottleneck.

jq is stable, I have never encountered a bug with it and I have never seen it getting stuck after years of usage. It is dependable and practical.

jq has helped me put out countless fires throughout my career. I should donate to it one day.

Post reply on HN