If you're into Clojure, check out https://github.com/borkdude/jet
Q: A faster re-implementaiton of jq written in Reason Native/OCaml
71–80 of 196 posts
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#72> Aside from that, q isn't feature parity with jq which is ok at this point, but jq contains a ton of functionality that query-json misses and some of the jq operations aren't native, are builtin with the runtime. In order to do a proper comparision all of this above would need to take into consideration.
> The report shows that q is between 2x and 5x faster than jq in all operations tested and same speed (~1.1x) with huge files (> 100M).
While faster for somethings....that's a pretty large set of caveats!
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#73Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#74Earlier quoted context omitted.
Yeah. Can you imagine trying to do a web search for ‘q’?
I can and it is lightly disturbing. https://imgur.com/a/yAOF31g ^_^
Appropriating Shepard Fairey's graphical style into a QAnon T-shirt and then wearing it to a Trump rally is an arresting masterwork of postmodernism. One wonders: is the wearer trolling the rally, or is he trolling himself? Perhaps we are all trolls. Perhaps we have all been trolled. HAND.
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#75Are we sure it should get a single-letter 'q' binary name though? Docs seem to point that it's short for 'query-json'? Why not call it 'query-json' and let the user decide that as a shell alias or whatever. Even the ubiquitous 'ls' and 'cd' are two characters.
Seems in the past hour he has renamed it to query-json and suggests that you set your own alias if you want something shorter.
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#76I'd long for such a tool with a better comprehensible query language.
Give jet a try! Uses a lightweight query language over EDN. If you're familiar with Clojure, it'll be very natural to use and if you're not familiar with Clojure, the query language used is very easy to pickup :) https://github.com/borkdude/jet/blob/master/doc/query.md
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#77Earlier 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.
Much Unix software today is written by people who really don't appreciate or understand Unix. It leads to things like Homebrew (early on, at least) completely taking over and breaking /usr/local; to command-line utilities using a single dash (-) precending both short and long option names (granted, --long-opts is a GNUism, but it's a well-established standard); commands that output color by default even when the output isn't a tty; etc.
It's not hard to fix things like this, but it exemplifies a lack of familiarity with the Unix command line. There are an enormous number of tools out there that only exist because people don't know how to chain together basic 1970s Unix text-processing tools in a pipeline.
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#78> Aside from that, q isn't feature parity with jq which is ok at this point, but jq contains a ton of functionality that query-json misses and some of the jq operations aren't native, are builtin with the runtime. In order to do a proper comparision all of this above would need to take into consideration. > The report shows that q is between 2x and 5x faster than jq in all operations tested and same speed (~1.1x) wit…
Adding most of the jq operations shoudn't affect performance at all, in fact If I endup implementing streaming could be even faster.
I have a issue to improve performance where I can push this forward: https://github.com/davesnx/query-json/issues/7
But sure, are caveats!
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#791) 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.
My most common jq usage is to copy and paste some json into quotes to make it easier to read. My second most common action is to chain curl and jq together. A replacement for jq that doesn’t use stdin is literally useless to me.
Re: Q: A faster re-implementaiton of jq written in Reason Native/OCaml
#801) 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]'
Nothing that can be fixed later?