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

51–60 of 281 posts

Re: A Faster Alternative to Jq

#51

Post by password4321 »

Kovah wrote: post #5

I wonder so often about many new CLI tools whose primary selling point is their speed over other tools. Yet I personally have not encountered any case where a tool like jq feels incredibly slow, and I would feel the urge to find something else. What do people do all day that existing tools are no longer enough? Or is it that kind of "my new terminal opens 107ms faster now, and I don't notice it, but I simply feel bet…

Optimization = good

Prioritizing SEO-ing speed over supporting the same features/syntax (especially without an immediately prominent disclosure of these deficiencies) = marketing bullshit

A faster jq except it can't do what jq does... maybe I can use this as a pre-filter when necessary.

Re: A Faster Alternative to Jq

#52

Post by [deleted] »

n_e wrote: post #11
Kovah wrote: post #5

I wonder so often about many new CLI tools whose primary selling point is their speed over other tools. Yet I personally have not encountered any case where a tool like jq feels incredibly slow, and I would feel the urge to find something else. What do people do all day that existing tools are no longer enough? Or is it that kind of "my new terminal opens 107ms faster now, and I don't notice it, but I simply feel bet…

I process TB-size ndjson files. I want to use jq to do some simple transformations between stages of the processing pipeline (e.g. rename a field), but it so slow that I write a single-use node or rust script instead.

[deleted]

Re: A Faster Alternative to Jq

#53

Post by swiftcoder »

Kovah wrote: post #5

I wonder so often about many new CLI tools whose primary selling point is their speed over other tools. Yet I personally have not encountered any case where a tool like jq feels incredibly slow, and I would feel the urge to find something else. What do people do all day that existing tools are no longer enough? Or is it that kind of "my new terminal opens 107ms faster now, and I don't notice it, but I simply feel bet…

Deal with really big log files, mostly.

If you work at a hyperscaler, service log volume borders on the insane, and while there is a whole pile of tooling around logs, often there's no real substitute for pulling a couple of terabytes locally and going to town on them.

Re: A Faster Alternative to Jq

#54

Post by jamespo »

dalvrosa wrote: post #47
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…

Fair, but agentic tooling can benefit quite a lot from this Opencode, ClaudeCode, etc, feel slow. Whatever make them faster is a win :)

It's not running jq locally that's causing that

Re: A Faster Alternative to Jq

#55

Post by hrmtst93837 »

Kovah wrote: post #5

I wonder so often about many new CLI tools whose primary selling point is their speed over other tools. Yet I personally have not encountered any case where a tool like jq feels incredibly slow, and I would feel the urge to find something else. What do people do all day that existing tools are no longer enough? Or is it that kind of "my new terminal opens 107ms faster now, and I don't notice it, but I simply feel bet…

[flagged]

Re: A Faster Alternative to Jq

#56

Post by Imustaskforhelp »

Jakob wrote: post #12
Kovah wrote: post #5

I wonder so often about many new CLI tools whose primary selling point is their speed over other tools. Yet I personally have not encountered any case where a tool like jq feels incredibly slow, and I would feel the urge to find something else. What do people do all day that existing tools are no longer enough? Or is it that kind of "my new terminal opens 107ms faster now, and I don't notice it, but I simply feel bet…

Speed is a quality in itself. We are so bugged down by slow stuff that we often ignore that and don’t actively search for another. But every now and then a well-optimised tool/page comes along with instant feedback and is a real pleasure to use. I think some people are more affected by that than others. Obligatory https://m.xkcd.com/1205

I am not sure if it was simon or pg who might've quoted this but I remembered a quote about that a 2 magnitude order in speed (quantity) is a huge qualititative change in it of itself.

Re: A Faster Alternative to Jq

#58

Post by wolfi1 »

forgive me my rant, but when I see "just install it with cargo" I immediately lose interest. How many GB do I have to install just to test a little tool? sorry, not gonna do that

Re: A Faster Alternative to Jq

#59

Post by majewsky »

shellac wrote: post #50
Bigpet wrote: post #3

When initially opening the page it had broken colors in light mode. For anyone else encountering it: switch to dark mode and then back to light mode to fix it.

I think this has just been fixed. A bit of dark mode was leaking into light in the css.

I still saw the same bug just now (Firefox on macOS).

Re: A Faster Alternative to Jq

#60

Post by httpsterio »

dalvrosa wrote: post #47
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…

Fair, but agentic tooling can benefit quite a lot from this Opencode, ClaudeCode, etc, feel slow. Whatever make them faster is a win :)

The 2ms it takes to run jq versus the 0.2ms to run an alternative is not why your coding agent feels slow.
Post reply on HN