3 ms·

why not contribute to the existing jq project instead of starting a new one? We have so many json query tools now it's insane.

sillysaurusx 3y ago
Fun, of course. Existing projects are boring almost by definition. And this is volunteer work.
deleted 3y ago
[deleted]
lilyball 3y ago
The obvious reason here is jaq makes some changes to semantics, changes which would be rejected by jq. Another likely reason is that it seems a motivation for jaq is improving the performance of jq. Any low-hanging fruit there in the jq implementation was likely handled a long time ago, so improving this in jq is likely to be hard. Writing a brand new implementation allows for trying out different ways of implementing the same functionality, and using a different language known for its performance helps too. Using a language like Rust also helps with the goal of ensuring correctness and safety.
- cryptonector 3y ago
  jq hasn't had much work done to make it fast though. There's two classes of performance problems: - implementation issues - language issues The latter is mainly a problem in `foreach` and also some missing ways to help programmers release references (via `$bindings`) that they no longer need. The former is mostly a matter of doing a variety of bytecode interpreter improvements, and maybe doing more inlining, and maybe finding creative ways to reduce the number of branches.
anonymoushn 3y ago
One reason to do this is that often performance improvements involve architectural overhauls that maintainers are unlikely to approve of.
cryptonector 3y ago
jq maintainer here. We love that there are multiple implementations of jq now. It does several things: a) it gives users more choices, b) it helps standardize the language (though we've not yet written a formal specification), c) it brings more energy to jq because the maintainers of the other tools have joined jq as maintainers. I also love that these alternative implementations relieve my growing dislike of C.

sillysaurusx 3y ago

Fun, of course. Existing projects are boring almost by definition. And this is volunteer work.

deleted 3y ago

[deleted]

lilyball 3y ago

The obvious reason here is jaq makes some changes to semantics, changes which would be rejected by jq. Another likely reason is that it seems a motivation for jaq is improving the performance of jq. Any low-hanging fruit there in the jq implementation was likely handled a long time ago, so improving this in jq is likely to be hard. Writing a brand new implementation allows for trying out different ways of implementing the same functionality, and using a different language known for its performance helps too. Using a language like Rust also helps with the goal of ensuring correctness and safety.

cryptonector 3y ago
jq hasn't had much work done to make it fast though. There's two classes of performance problems: - implementation issues - language issues The latter is mainly a problem in `foreach` and also some missing ways to help programmers release references (via `$bindings`) that they no longer need. The former is mostly a matter of doing a variety of bytecode interpreter improvements, and maybe doing more inlining, and maybe finding creative ways to reduce the number of branches.

anonymoushn 3y ago

One reason to do this is that often performance improvements involve architectural overhauls that maintainers are unlikely to approve of.

cryptonector 3y ago

jq maintainer here. We love that there are multiple implementations of jq now. It does several things: a) it gives users more choices, b) it helps standardize the language (though we've not yet written a formal specification), c) it brings more energy to jq because the maintainers of the other tools have joined jq as maintainers. I also love that these alternative implementations relieve my growing dislike of C.