Live data from Hacker News

Q: A faster re-implementaiton of jq written in Reason Native/OCaml

github.com

51–60 of 196 posts

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#51

Great! Now improve the syntax!

How, though? I agree that jq's syntax isn't exactly the most straightforward, and it gets raised as a point of criticism anytime jq is mentioned, but its scripting language seems like a pretty good compromise between compactness and rich features. Replacing that with, say, traditional command line flags would make it a lot less useful for me, I'd probably have to build much longer pipe-chains to do things that are re…

Just because jq is very well stablished doesn't mean their APIs are well designed and we shoudn't improved because will break existing scripts.

There're a lot of quirks from the usage of it and people struggling with learning such a great tool, so in the area of query-json it will try to make a better interface for users.

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#54
post #52
post #47

1) refuses to operate on stdin; requires a filename argument, which is so irritating. 2) doesn't accept values that jq accepts % time jq -r '[expression]'

That's super weird, I think most people use jq for bash pipelines.

Yes, I don't understand how people end up with assertions that the filename is a require argument. At least we've got /dev/stdin or /proc/self/fd/0 as workarounds.

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#55

Earlier quoted context omitted.

I can and it is lightly disturbing. https://imgur.com/a/yAOF31g ^_^

Gqd, look how that looks like 666, edit distance is 3. Turn around the letters. Here have a timeline: https://imgur.com/a/aQYnKLm

"Gqd" = graphene quantum dot ?

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#56
post #48

Earlier quoted context omitted.

Out of interest, what created a 90GB JSON file?

I don't think it's quite 90GB, but I've processed Wikidata dumps in the same order of magnitude before (which are one JSON object per line) with jq, and it could've certainly been faster.

I was wondering about that - whether they are one single JSON array/object or one per line.

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#57
post #54
post #52

Earlier quoted context omitted.

That's super weird, I think most people use jq for bash pipelines.

Yes, I don't understand how people end up with assertions that the filename is a require argument. At least we've got /dev/stdin or /proc/self/fd/0 as workarounds.

files might be faster, because you can mmap them?

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#59

The speed is not concern for me. I am wondering if there something better than `jq` in terms of syntax. Whenever I want to get something more that just prettify json output in the console or simply get value by specific field name I have a problem, for me it is just difficult to remember jq syntax without looking into history. As well have in my notes links to examples like this one https://mosermichael.github.io/jq-…

Check out jql [https://github.com/cube2222/jql] and oj [https://github.com/ohler55/ojg]

Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml

#60

Curious, any description as to why it's faster? Something intrinsic to Reason Native/OCaml? Architectural changes? Reduced feature set?

Well it is missing a ton of jq functionality, it's possible that in that list is something causing the performance degradation.
Post reply on HN