Live data from Hacker News

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

github.com

231–240 of 254 posts

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

#231

Earlier quoted context omitted.

> Jaques is the French spelling of Jack/Jaak/Jak/Jaq. They're all pronounced the same They're not, though. The French pronunciation of 'j', as in the word Jaques is /ʒ/. In English, 'j' at the beginning of the word 'Jack' is pronounced /dʒ/. And 'Jaak' makes me think of Dutch, where that 'j' is pronounced as /j/.

In the prescriptivists fantasyland, yes. In the real world, the descriptivist realizes an individual's pronunciation of the concept labelled Jac/Jack/Jacques/Jacq/Jak/etc. depends much more on the their personal context and stylistic choice than the spelling used. I've heard many folks (American and otherwise) pronounce "Jack" many times in my life, and the range of utterances very comfortably includes Pépin's own "J…

[flagged]

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

#232

Earlier quoted context omitted.

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…

You can also mimic gron, including support for yaml with yq -o=props my-file.yaml

Doesn't work in my terminal. When you recommend yq behavior, please specify which yq you're using. There are at least two incompatible implementations.

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

#233

I think the best alternative for JQ is datawave, but it is not open source. https://dataweave.mulesoft.com/

The latest blog post is about open sourcing it from last September. So the process of open sourcing dataweave takes at least 15 months.

It have some learning curve, but it actually makes sense when you get used to it and work for other format too. It is much better than other transformation language, and you can even call Java.

I think they kind of stuck in the development, even the mule engine only have one active developer from the github commit ….

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

#234

Earlier quoted context omitted.

In the prescriptivists fantasyland, yes. In the real world, the descriptivist realizes an individual's pronunciation of the concept labelled Jac/Jack/Jacques/Jacq/Jak/etc. depends much more on the their personal context and stylistic choice than the spelling used. I've heard many folks (American and otherwise) pronounce "Jack" many times in my life, and the range of utterances very comfortably includes Pépin's own "J…

[flagged]

There’s no single way “native” speakers say any word, and the fact that you think there is shows you have had no exposure to the massive diversity of American accents.

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

#235
post #99

It's so awesome when projects shout out other projects that they're similar to or inspired by or not replacements for. I learned about https://github.com/yamafaktory/jql from the readme of this project and it's what I've been looking for for a long time, thank you! That's not to take away from JAQ by any means I just find the JQ style syntax uber hard to grokk so jql makes more sense for me.

Nice find. I think I'll try it out. Although I was hoping for a real SQL type experience. I don't understand why no one just copies SQL so I can write a query like "SELECT * FROM $json WHERE x>1". Everyone seems to want to invent their own new esoteric symbolic query language as if everything they do is a game of code golf. I really wish everyone would move away from this old Unix mentality of extremely concise, yet…

nushell and pwsh. I'm not familiar with nushell, but pwsh offers where, select, foreach, group, sort.

N.B. those aliases are not created by default on *nix

It's pipeline-based and procedural, but you can be very declarative in data processing

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

#236
post #210

Earlier quoted context omitted.

How does that usually play out in the Rust ecosystem? Lots of dependencies tell me there's a huge risk of the dependencies becoming inherently incompatible with each other over time, making maintenance a major task. How will this compile in say, 2 years?

Because of the lockfile, it will use the same library versions when compiling again in the future. The main question for "will this compile" is whether the Rust compiler is sufficiently backwards-compatible, which (at least from my experience) it certainly is. Also re "lots of dependencies": This is kind of unavoidable in Rust because the stdlib is deliberately very lean, and focuses on basic data structures that are…

I understand the concept of a lock file and they are a blessing, but inevitably one will need to upgrade at least one of the dependencies. Whether this is due to desired functionality or a bug, it is bound to happen.

Lock files won't solve that problem if one of the other libraries will be incompatible. Add more time and the problem compounds. Major problem in e.g. the npm ecosystem.

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

#237

Earlier quoted context omitted.

What would be your choice if you would need to write high performing CLI tool?

I think it's more the hand-in-handedness that seems to exist between "rewrite an existing, mature tool" and doing it in Rust. Half the time it's hard for me to know which caused which — the need for the tool, or the desire to rewrite something in Rust.

yeah, you are right

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

#238
post #99

It's so awesome when projects shout out other projects that they're similar to or inspired by or not replacements for. I learned about https://github.com/yamafaktory/jql from the readme of this project and it's what I've been looking for for a long time, thank you! That's not to take away from JAQ by any means I just find the JQ style syntax uber hard to grokk so jql makes more sense for me.

Nice find. I think I'll try it out. Although I was hoping for a real SQL type experience. I don't understand why no one just copies SQL so I can write a query like "SELECT * FROM $json WHERE x>1". Everyone seems to want to invent their own new esoteric symbolic query language as if everything they do is a game of code golf. I really wish everyone would move away from this old Unix mentality of extremely concise, yet…

OctoSQL[1] does a pretty good job of allowing you to query JSON (and CSV) with SQL.

[1] https://github.com/cube2222/octosql

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

#239

Earlier quoted context omitted.

There's also this awesome tool to make JSON interactively navigable in the terminal: https://fx.wtf

https://jless.io/ is similar, and will give you jq selectors so the two combine very well. (fx might have that feature too, I dunno)

Ah thanks, jless is actually the one I was originally thinking of and trying to find! :D

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

#240
post #156

How have you been using jq? It is more adhoc for exploring JSON files during development/data analysis or in programs that run in production?

I use it as a "JSON library for bash". :-)

Not really in "production", but I have a lot of small-ish shell scripts all over the place, mostly in ~/bin, and some in CI (GitHub Actions) as well.

Post reply on HN