What is jj's long term goal?

[MajorDallas]

tl;dr: I guess if I'm asking for anything with all the following, it's clarification: is feature-parity with jq an eventual goal for jj, or is it meant to only ever serve for easier access of JSON values in Go app code?

Although tidwall/gjson#161 provided one necessary capability, this kind of task remains impossible with GJSON path syntax and jj. I have a nested structure, but I'm only interested in how many times a certain key has the same value across all objects:

# diagnostics.json
{
  "nodes": {
    "000-000-0000": {
      "node_type": "server"
    },
    "000-111-0001": {
      "node_type": "asav"
    },
    "222-000-0202": {
      "node_type": "server"
    },
  } 
}

In other words, how many times is node_type "server", "asav", or any other value which I can't know ahead of time?

With jq, this is fairly straightforward:

jq '.nodes 
  | [.[].node_type]  # Makes an array of all sub-objects' node_type values
  | group_by(.)      # Sorts the array and groups alike elements into nested arrays
  | map(             # Makes an object for each nested array like {"key: "server", "value": 2}
    { "key": (.[0]), "value": . | length }
  ) | from_entries  # Turn the arrayed objects into a single object
' diagnostics.json

# {
#    "server": 2,
#    "asav": 1
# }

With jj, I can get as far as making a list of the node_types with

nodes.@values.#.node_type

# ["server", "asav", "server"]

but there is no way to group or even sort this array for further transformation using just jj.

I understand that GJSON is a Go library and those kinds of operations are, not unreasonably, expected to be implemented in app code. However, the README presents jj as an alternative to jq, which describes itself as "sed for JSON." That's a few steps beyond what is currently possible with jj and GJSON's path syntax, so jj is only a viable alternative for a subset of problems which jq aims to address despite its clear speed advantage.

[tidwall]

Sorry for the slow response.

Jq is pretty awesome. If you plan on doing advanced stuff like you show in your example then I recommend sticking with jq.

What is jj's long term goal?

I don't have a long term goal, but a few years back I had a use case where needed to use a gjson path from a bash script, so I wrote jj. The gjson syntax has matured quite a bit over the past few years, but I doubt it will ever do all the fancy stuff that jq does. Sadly I don't have the bandwidth to make it that rad. Maybe I'll set fire under my ass and knock out some new features in the future.

jj is only a viable alternative for a subset of problems which jq aims to address despite its clear speed advantage.

Pretty much. Jj is an alternative, but that doesn't necessarily mean I recommend jj over jq. Unless you are needing gjson syntax or want to fetch a deep value using a simple path. Jj is very fast at getting getting a single value.