Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Faster Alternative to Jq

micahkepe.com

Post reply on HN
Print view View original

151–160 of 281 posts

Re: A Faster Alternative to Jq

#151

Post by alsetmusic »

j1elo wrote: post #76
1a527dd5 wrote: post #43

I appreciate performance as much as the next person; but I see this endless battle to measure things in ns/us/ms as performative. Sure there are 0.000001% edge cases where that MIGHT be the next big bottleneck. I see the same thing repeated in various front end tooling too. They all claim to be _much_ faster than their counterpart. 9/10 whatever tooling you are using now will be perfectly fine. Example; I use grep a…

Whenever you have this kind of impressions on some development, here are my 2 cents: just think "I'm not the target audience". And that's fine. The difference between 2ms and 0.2ms might sound unneeded, or even silly to you. But somebody, somewhere, is doing stream processing of TB-sized JSON objects, and they will care. These news are for them.

I remember when I was coming up on the command line and I'd browse the forums at unix.com. Someone would ask how to do a thing and CFAJohnson would come in with a far less readable solution that was more performative (probably replacing calls to external tools with Bash internals, but I didn't know enough then to speak intelligently about it now).

People would say, "Why use this when it's harder to read and only saves N ms?" He'd reply that you'd care about those ms when you had to read a database from 500 remote servers (I'm paraphrasing. He probably had a much better example.)

Turns out, he wrote a book that I later purchased. It appears to have been taken over by a different author, but the first release was all him and I bought it immediately when I recognized the name / unix.com handle. Though it was over my head when I first bought it, I later learned enough to love it. I hope he's on HN and knows that someone loved his posts / book.

https://www.amazon.com/Pro-Bash-Programming-Scripting-Expert...

Re: A Faster Alternative to Jq

#153

Post by TomNomNom »

ivaniscoding wrote: post #145
regus wrote: post #137

Jq's syntax is so arcane I can never remember it and always need to look up how to get a value from simple JSON.

Shameless plug, but you might like this: https://github.com/IvanIsCoding/celq jq is the CLI I like the most, but sometimes even I struggled to understand the queries I wrote in the past. celq uses a more familiar language (CEL)

Cool tool! Really appreciate the shoutout to gron in the readme, thanks! :)

Re: A Faster Alternative to Jq

#156

Post by latexr »

amelius wrote: post #148
NSPG911 wrote: post #142

Earlier quoted context omitted.

I also genuinely hate using jq. It is one of the only things that I rely heavily on AI.

At that point why don't we ask the AI directly to filter through our data? The AI query language is much more powerful.

Because the output you get can have hallucinations, which don’t happen with a deterministic tool. Furthermore, by getting the `jq` command you get something which is reusable, fast, offline, local, doesn’t send your data to a third-party, doesn’t waste a bunch of tokens, … Using an LLM to filter the data is worse in every metric.

Re: A Faster Alternative to Jq

#157

Post by amelius »

latexr wrote: post #156
amelius wrote: post #148

Earlier quoted context omitted.

At that point why don't we ask the AI directly to filter through our data? The AI query language is much more powerful.

Because the output you get can have hallucinations, which don’t happen with a deterministic tool. Furthermore, by getting the `jq` command you get something which is reusable, fast, offline, local, doesn’t send your data to a third-party, doesn’t waste a bunch of tokens, … Using an LLM to filter the data is worse in every metric.

You can use a local LLM and you can ask it to use tools so it is faster.

Re: A Faster Alternative to Jq

#158

Post by ivaniscoding »

xpe wrote: post #149
ivaniscoding wrote: post #145

Earlier quoted context omitted.

Shameless plug, but you might like this: https://github.com/IvanIsCoding/celq jq is the CLI I like the most, but sometimes even I struggled to understand the queries I wrote in the past. celq uses a more familiar language (CEL)

CEL looks interesting and useful, though it isn't common nor familiar imo (not for me at least). Quoting from https://github.com/google/cel-spec # Common Expression Language The Common Expression Language (CEL) implements common semantics for expression evaluation, enabling different applications to more easily interoperate. ## Key Applications - Security policy: organizations have complex infrastructure and need com…

That’s some fair criticism, but the same page tells that the language wanted to have a similar syntax to C and JavaScript.

I think my personal preference for syntax would be Python’s. One day I want to try writing a query tool with https://github.com/pydantic/monty

Re: A Faster Alternative to Jq

#159

Post by latexr »

raverbashing wrote: post #115
1a527dd5 wrote: post #43

I appreciate performance as much as the next person; but I see this endless battle to measure things in ns/us/ms as performative. Sure there are 0.000001% edge cases where that MIGHT be the next big bottleneck. I see the same thing repeated in various front end tooling too. They all claim to be _much_ faster than their counterpart. 9/10 whatever tooling you are using now will be perfectly fine. Example; I use grep a…

Yes I don't think I remember one case where jq wasn't fast enough Now what I'd really want is a jq that's more intuitive and easier to understand

> Now what I'd really want is a jq that's more intuitive and easier to understand

Unfortunately I don’t recall the name, but there was something submitted to HN not too long ago (I think it was still 2026) which was like jq but used JavaScript syntax.

Re: A Faster Alternative to Jq

#160

Post by d35007 »

regus wrote: post #137

Jq's syntax is so arcane I can never remember it and always need to look up how to get a value from simple JSON.

That’s interesting! Can you say a little more? I find jq’s syntax and semantics to be simple and intuitive. It’s mostly dots, pipes, and brackets. It’s a lot like writing shell pipelines imo. And I tend to use it in the same way. Lots of one-time use invocations, so I spend more time writing jq filters than I spend reading them.

I suspect my use cases are less complex than yours. Or maybe jq just fits the way I think for some reason.

I dream of a world in which all CLI tools produce and consume JSON and we use jq to glue them together. Sounds like that would be a nightmare for you.

Post reply on HN