Live data from Hacker News

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

github.com

71–80 of 254 posts

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

#71
post #51

Earlier quoted context omitted.

No, /dʒæk/ is not /ʒak/

Found the Frenchmen :) Yes they're slightly different in theory, but not in any way that would prohibit mutual understanding. Besides, if you're telling anyone about this library you're most certainly going to spell it out anyways.

I'm American and pronounce Jacques and Jack the way they described. If someone said [ʒak], I would transcribe it as Jacques, and if someone said [dʒæk], I would transcribe it as Jack. It may be a French name, but it's not very foreign. (If I heard [dʒak], I would assume the speaker is British and transcribe it as Jack).

I was confused reading people say that Jacques is pronounced the same as Jack, so it does seem like mutual understanding is inhibited.

It's just like how, even though Johann is a German name (though borrowed from Latin), I know to pronounce it in English not as [dʒoʊhæn] (the naive English pronunciation), but as [joʊhan], which is similar to the German pronunciation, [johan].

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

#72
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.

It is a little early to say, but I have been learning how nushell deals with structured data and it seems like it is very usable for simple cases to produce readable one-liners, and if you need to bring out the big guns the shell is also a full fledged scripting language. Don't know about how efficient it is though. It needs to justify moving to a completely different shell, but the way you deal with data in general…

From the data side, nushell uses polars for querying tabular data so it should be pretty fast. Not sure about its scripting language.

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

#73
post #32

Somewhat off-topic, but is there a tool which integrates something like this/jq/fx and API requests? I’d like to be able to do some ETL-like operations and join JSON responses declaratively, without having to write a script.

Is there anything out there like "SELECT * FROM " http:// ..."?

My shell will do that

    open http://… | select * where …
    # FROM can be omitted because you’re loading a pipe

https://murex.rocks/optional/select.html

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

#74
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…

This looks some much better as an ad-hoc tool. Would be cool if it supported more formats - plist, yaml, xml (hoow to do body, or conflicting attr/elements)

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

#75

I started using yq over jq. Any significant differences?

Which yq? I prefer https://github.com/mikefarah/yq to https://github.com/kislyuk/yq .

I prefer the former, single static binary which works great on workstations and CI alike, the latter requires python as well as jq as it's a wrapper

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

#76
post #32

Somewhat off-topic, but is there a tool which integrates something like this/jq/fx and API requests? I’d like to be able to do some ETL-like operations and join JSON responses declaratively, without having to write a script.

Is there anything out there like "SELECT * FROM " http:// ..."?

I think a query language would be great, with a way to subquery/chain data from previous requests (e.g. by jsonpath) to subsequent ones.

The closest I’ve gotten is to wrap the APIs with GraphQL. This achieves joining, but requires strict typing and coding the schema+relationships ahead of time which restricts query flexibility for unforeseen edge cases.

Another is a workflow automation tool like n8n which isn’t as strict and is more user-friendly, but still isn’t very dynamic either.

Postman supports chaining, but in a static way with getting/setting env variables in pre/post request JS scripts.

Bash piping is another option, and seems like a more natural fit, but isn’t super reusable for data sources (e.g. with complex client/auth setup) and I’m not sure how well it would support batch requests.

It would be an interesting tool/language to build, but I figure there has to be a solution out there already.

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

#77

Earlier quoted context omitted.

To me, the proper pronunciation of Jacques sounds more like "Jock", so it does seem to be more than barely significant.

Does this https://www.bing.com/videos/riverview/relatedvideo?q=Jacques... really sound like Jock to you? There is a significant sharp "æ" sound, the same as in Jack/dʒæk

It sounds like [a] to me, not [æ].

The a in the name Jacques is pronounced as in the word father.

The a in the name Jack is pronounced as in cat.

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

#78
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.

Maybe like SQL for relational algebra? Codd made two query languages that were "too difficult for mortals to use". (B-trees for performance was a separate issue)

But jq's strength is its syntax - the difficulty is the semantics.

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

#79
post #15

Earlier quoted context omitted.

$ 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 th…

FWIW, I see no difference. (hyperfine 1.17.0, jq 1.7, jaq 1.2.0)

  $ hyperfine -N -w 100 -m 1000 -L bin jq,jaq "echo '[1,2,3]' | {bin} '.[1]'"
  Benchmark 1: echo '[1,2,3]' | jq '.[1]'
    Time (mean ± σ):       3.4 ms ±   1.7 ms    [User: 0.6 ms, System: 2.6 ms]
    Range (min … max):     0.7 ms …   5.8 ms    1000 runs
 
  Benchmark 2: echo '[1,2,3]' | jaq '.[1]'
    Time (mean ± σ):       3.4 ms ±   1.7 ms    [User: 0.5 ms, System: 2.7 ms]
    Range (min … max):     0.7 ms …   5.8 ms    1000 runs
 
  Summary
    echo '[1,2,3]' | jq '.[1]' ran
      1.00 ± 0.71 times faster than echo '[1,2,3]' | jaq '.[1]'

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

#80
post #3

While jq is a very powerful tool, I've also been using DuckDB a lot lately. SQL is a much more natural language if the data is somewhat tabular.

I like textql [0] better for this use case, as it's simpler in my mind. [0] https://github.com/dinedal/textql

textql doesn't seem to work with JSON. I think the grandparent comment meant that the data was in a table of sorts, represented in JSON.
Post reply on HN