Hacker News Reader

Comment by justsomeuser | Hacker News Reader

I already have a JSON query language - it’s JavaScript.

> Queries are 80% shorter than imperative code

From the examples they look the same length as the corresponding JS I would write, maybe slightly longer.

What are the advantages to using this language over JS?

JS has a fast JIT which would make filtering data fast. How does this query language compare in performance? Does it have indexes?

View on HN

This does some clever stuff in the background, e.g. query optimization and performing the computations of a 'for'-loop concurrently (potentially over multiple machines in a cluster). So in my experience there was a bit of latency for the query to execute, but then it executes faster and on much larger datasets than regular JS could handle.

Just like how you could easily manipulate tabular data using numpy or pandas (or excel), but SQL allows you to do it declaratively, which has benefits in some cases.

CouchDB has been running distributed Map/Reduce queries on JSON data for over a decade. It’ll be interesting to see how this compares.

Thank you for your comment.

The motivation for JSONiq and RumbleDB is discussed in this recent paper, the core argument is data independence:

https://arxiv.org/abs/1910.11582v3

JSONiq is a functional language and thus makes it easy to scale to collections that have billions of objects.

A notable difference with JavaScript is that JSONiq has the FLWOR expression, which is similar to, but more generic than, a SQL statement.

Good points. JSON processing tools I find helpful in addition to JavaScript include Gron aka "grep for JavaScript" ( https://github.com/tomnomnom/gron ), jq for querying, json_pp for pretty-printing and `bat` for syntax highlighting.

it's just less code - instead of writing a series of buggy loops with null checks and string concatenations all over the place, you just writing a line of declaration and it deals with all that for you.

Reply on news.ycombinator.com