Live data from Hacker News

Zq: An easier and faster alternative to jq

brimdata.io

61–70 of 237 posts

Re: Zq: An easier and faster alternative to jq

#61
In Next Generation Shell (author here), it is not as ergonomic (yet?) but on the other hand it's a fully fledged no-nonsense programming language... and I claim quite a readable.

good_data = fetch("openlibrary.json").docs.filter({"author_name": Arr, "publish_year":Arr})

good_data.map({{"title": A.title, "author_name": A.author_name[0], "publish_year": A.publish_year[0]}}).group("author_name").mapv(len).sortv((>=)).limit(3)

Re: Zq: An easier and faster alternative to jq

#62

If jq is getting too slow for you (that's never happened for me), it really seems like it's time to put your data in a database like sqlite or duckdb at least. Incidentally there are many tools that help you do this like dsq [0] (which I develop), q [1], textql [2], etc. [0] https://github.com/multiprocessio/dsq [1] https://github.com/harelba/q [2] https://github.com/dinedal/textql

I don’t agree. There is a great deal of room for improvement in jq performance. I profiled one invocation and it spent the majority of its time asserting that the stack depth was lower than some amount, which is crazy. I rebuilt it with NDEBUG defined and it was seriously ten times faster, but it’s not safe to run it that way because it has asserts with side effects, which is also crazy.

Rewriting all or parts of it in C++ would make it dramatically faster. I would start by ripping out the asserts and using a different strtod which they spend an awful lot of time in.

Re: Zq: An easier and faster alternative to jq

#63
Why all the hate HN?

I feel the author makes his case clearly, then presents an alternative. Underneath all this is a ton of work, for which I applaud OP.

It may not scratch your particular itch, but come on!

Being an ass on HN is a choice. It happens far too often, and I wish everyone would just dial it back.

Re: Zq: An easier and faster alternative to jq

#64
I'm working on a JSONiq based implementation to jointly process JSON data and XML. The compiler uses set-oriented processing (and thus uses hash joins for instance wherever applicable) and is meant to provide a base for JSON based database systems with shared common optimizations (but can also be used as a standalone in-memory query processor):

http://brackit.io

The language itself borrows a lot of concepts from functional languages as higher order functions, closures... you can also develop modules with functions for easy reuse...

A simple join for instance looks like this:

        let $stores :=
        [
          { "store number" : 1, "state" : "MA" },
          { "store number" : 2, "state" : "MA" },
          { "store number" : 3, "state" : "CA" },
          { "store number" : 4, "state" : "CA" }
        ]
        let $sales := [
           { "product" : "broiler", "store number" : 1, "quantity" : 20  },
           { "product" : "toaster", "store number" : 2, "quantity" : 100 },
           { "product" : "toaster", "store number" : 2, "quantity" : 50 },
           { "product" : "toaster", "store number" : 3, "quantity" : 50 },
           { "product" : "blender", "store number" : 3, "quantity" : 100 },
           { "product" : "blender", "store number" : 3, "quantity" : 150 },
           { "product" : "socks", "store number" : 1, "quantity" : 500 },
           { "product" : "socks", "store number" : 2, "quantity" : 10 },
           { "product" : "shirt", "store number" : 3, "quantity" : 10 }
        ]
        let $join :=
          for $store in $stores, $sale in $sales
          where $store=>"store number" = $sale=>"store number"
          return {
            "nb" : $store=>"store number",
            "state" : $store=>state,
            "sold" : $sale=>product
          }
        return [$join]
Of course you can also group by, count, order by, nest FLWOR clauses...

Re: Zq: An easier and faster alternative to jq

#65
post #25

Earlier quoted context omitted.

I didn't realize jq was missing a maintainer, it's one of my most used CLI tools.

It really is a fundamental problem where lots of these important projects aren't maintained simply because the reality is the maintainers can't beat the economics of a lot of rich freeloaders having no real short term incentive to compensate these maintainers..

It’s not though, because in this case the (ex-)maintainer works at a Wall St firm.

Re: Zq: An easier and faster alternative to jq

#66
post #63

Why all the hate HN? I feel the author makes his case clearly, then presents an alternative. Underneath all this is a ton of work, for which I applaud OP. It may not scratch your particular itch, but come on! Being an ass on HN is a choice. It happens far too often, and I wish everyone would just dial it back.

Do not confuse critique with hate.

This place has a high standard for new tools and libraries, particularly one that claims to be better in any stretch ("faster" and "easier"). If this was say, a college student learning programming and presenting it as "hey I made a jq alternative and I believe it's easier and faster" I imagine it would solicit more softened feedback.

Come prepared, and ready to defend your stance. If you can't take the heat, don't come in the kitchen.

Re: Zq: An easier and faster alternative to jq

#67
post #62

If jq is getting too slow for you (that's never happened for me), it really seems like it's time to put your data in a database like sqlite or duckdb at least. Incidentally there are many tools that help you do this like dsq [0] (which I develop), q [1], textql [2], etc. [0] https://github.com/multiprocessio/dsq [1] https://github.com/harelba/q [2] https://github.com/dinedal/textql

I don’t agree. There is a great deal of room for improvement in jq performance. I profiled one invocation and it spent the majority of its time asserting that the stack depth was lower than some amount, which is crazy. I rebuilt it with NDEBUG defined and it was seriously ten times faster, but it’s not safe to run it that way because it has asserts with side effects, which is also crazy. Rewriting all or parts of it…

Fair point! I don't mean to say jq performance can't or shouldn't be improved.

Just that jq does two things: 1) ingest and 2) query.

If you're doing a bunch of exploration on a single dataset in one period of time or if the dataset is large enough and you're selecting subsets of it, you can ingest the data into a database (and optionally toggle indexes).

Then you can query as many times as you want and not worry about ingest again until your data changes.

All three of the tools I listed have variations of this sort of caching of data built in. For dsq and q with caching turned on, repeat queries against files with the same hashsum only do queries against data already in SQLite, no ingestion.

Re: Zq: An easier and faster alternative to jq

#68

The name of its corporate progenitor may leave a bad taste in some mouths, but I highly recommend PowerShell for this sort of thing. It's cross platform, MIT licensed, and comes with excellent JSON parsing and querying capabilities. Reading, parsing, and querying JSON to return all red cars: Get-Content cars.json | ConvertFrom-Json | ? { $_.color -eq 'red' } The beauty of this is that the query syntax applies not jus…

Agreed— PowerShell is really nice for this, as are some of the other shells it has inspired.

Re: Zq: An easier and faster alternative to jq

#69

jq is incredibly powerful and I'm using it more and more. Even better, there is a whole ecosystem of tools that are similar or work in conjunction with jq: * jq (a great JSON-wrangling tool) * jc (convert various tools’ output into JSON) * jo (create JSON objects) * yq (like jq, but for YAML) * fq (like jq, but for binary) * htmlq (like jq, but for HTML) List shamelessly stolen from Julia Evans[1]. For live links see…

I would definitely add dasel to that list. It's become my de facto serialized data converter, and regularly use it to convert between csv, toml, yaml, json, and xml using jq-ish syntaxes.

https://github.com/tomwright/dasel

Re: Zq: An easier and faster alternative to jq

#70
post #20

These guys must really hate functional programming. I can see where jq might confuse someone new to it, but their replacement is irregular, stateful, still difficult, and I don't even see variable binding or anything. jq requires you to understand that `hello|world` will run world for each hello, passing the world out values to either the next piped expression, the wrapping value-collecting list, or printing them to…

Variables exist in zq, "this" is a reserved word: echo {x:1} | zq 'x := x+1' -
Post reply on HN