Live data from Hacker News

Jaq – A jq clone focused on correctness, speed, and simplicity

github.com

11–20 of 254 posts

Re: Jaq – A jq clone focused on correctness, speed, and simplicity

#12
post #4

Earlier quoted context omitted.

As an outsider, getting your code merged into a popular open source project involves a political process of convincing the maintainers that your fix should be addressed, and then convincing them they should merge your code. Writing a fork involves sitting down at your laptop and coding it out.

Plus of course everything needs rewritten in rust /s.

  $ hyperfine -w 100 -m 1000 -L bin jq,jaq "echo '[1,2,3]' | {bin} '.[1]'"

  Summary
    echo '[1,2,3]' | jaq '.[1]' ran
      1.57 ± 0.15 times faster than echo '[1,2,3]' | jq '.[1]'
Bring on the competition!

Re: Jaq – A jq clone focused on correctness, speed, and simplicity

#14
post #6

I applaud this project's focus on correctness and efficiency, but I'd also really like a version of `jq` that's easy to understand without having to learn a whole new syntax. `jq` is a really powerful tool and `jaq` promises to be even more powerful. But, as a system administrator, most lot of the time that I'm dealing with json files, something that behaved more like grep would be sufficient.

Have you tried `gron`? It converts your nested json into a line by line format which plays better with tools like `grep` From the project's README: ▶ gron " https://api.github.com/repos/tomnomnom/gron/commits?per_page... " | fgrep "commit.author" json[0].commit.author = {}; json[0].commit.author.date = "2016-07-02T10:51:21Z"; json[0].commit.author.email = "mail@tomnomnom.com"; json[0].commit.author.name = "Tom Hudson…

Thank you so much. This seems like a saner approach for some simpler use cases.

It flattens the structure. And makes for easy diffing.

Re: Jaq – A jq clone focused on correctness, speed, and simplicity

#15

Earlier quoted context omitted.

Plus of course everything needs rewritten in rust /s.

$ hyperfine -w 100 -m 1000 -L bin jq,jaq "echo '[1,2,3]' | {bin} '.[1]'" Summary echo '[1,2,3]' | jaq '.[1]' ran 1.57 ± 0.15 times faster than echo '[1,2,3]' | jq '.[1]' Bring on the competition!

As the benchmarks show, jaq is pretty significantly faster than jq.

I've commented before that I expect Rust to be a language that is generally faster than even C or C++ in a way that's hard to capture in small benchmarks, because the borrow checker permits code to be written safely that does less copying that other languages have to do for safety. Given the nature of what jq/jaq does, I wouldn't be surprised that that is some of the effect here. It would be interesting to instrument them up with tools that can track the amount of memory traffic each benchmark does to compare (that is, not memory used but total traffic in and out of RAM); I bet the Rust code shows a lot less.

Re: Jaq – A jq clone focused on correctness, speed, and simplicity

#16

[flagged]

I think we all understand this to some degree, but working on open source, outside of a few flashy projects, is some of the most thankless work there is. And contributing an immense amount of difficult work (such as perf and correctness improvements across the board) to a repo that you don't own and won't be recognized for is somehow significantly more thankless than that. For whatever reason, people only really care about the creator of a project, and virtually no one else.

For instance, do you know who Junio Hamano is? Oh, he's just a guy who's been maintaining a fairly minor project called Git for the last 15 years. But everyone can connect Linus Torvalds with git, even though he only worked on it consistently for a year or two before leaving it [1].

Also, and I think we all know this too, but working on someone else's codebase kinda sucks. Greenfield is so much more fun. It's a shame, but I'm really not surprised in the slightest.

[1]: https://github.com/git/git/graphs/contributors

Re: Jaq – A jq clone focused on correctness, speed, and simplicity

#19

[flagged]

How does this relate to navigating structured documents? Even if you use XML, presumably you will want to programmatically navigate/query it at some point.

Luckily XQuery, XSLT and XST are all XML

/s

Re: Jaq – A jq clone focused on correctness, speed, and simplicity

#20

[flagged]

How does this relate to navigating structured documents? Even if you use XML, presumably you will want to programmatically navigate/query it at some point.

You don't understand the power of XML and committee design. XPath could do almost everything. And XSLT in skillful hands could give birth to a blackhole due to information density alone.
Post reply on HN