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.

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.

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.

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

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